Představ si, že provozuješ web pro padesát klientů a každý má vlastní doménu, vlastní obsah a vlastní data. A teď si představ, že to celé běží z jednoho jediného kódu, který spravuješ na jednom místě. Tomu se říká multi-tenant architektura a sám na ní stavím celou platformu. Ukážu ti, jak funguje, jaké má modely a kde číhají rizika, o kterých se moc nemluví.
Co je tenant a proč na tom záleží
Tenant je v tomhle světě jeden klient, jedna oddělená jednotka. Každý tenant má svoje data, vzhled, doménu a uživatele, ale technicky všichni sdílejí stejný kód aplikace. Když opravím chybu nebo přidám funkci, dostanou ji všichni klienti naráz, bez nasazování padesáti kopií.
Opak je single-tenant, kdy každý klient dostane vlastní kopii aplikace i databáze. To zní bezpečně, ale při větším počtu klientů se to stane neudržitelné. Padesát kopií znamená padesát aktualizací, padesát záloh a padesát míst, kde se něco rozbije.
Tři modely izolace dat
Klíčová otázka multi-tenant systému zní: kde a jak oddělit data klientů, aby jeden nikdy neviděl data druhého. Existují tři hlavní přístupy:
- Sdílená databáze, sdílené tabulky: všichni klienti jsou ve stejných tabulkách, odlišuje je sloupec tenant_id. Nejlevnější a nejjednodušší na provoz, ale klade nejvyšší nároky na disciplínu v kódu.
- Sdílená databáze, oddělená schémata: každý klient má vlastní sadu tabulek v jedné databázi. Lepší izolace, vyšší složitost správy.
- Oddělené databáze: každý klient má fyzicky vlastní databázi. Nejsilnější izolace, ale provozně nejnáročnější a nejdražší.
| Model | Izolace | Náklady | Vhodné pro |
|---|---|---|---|
| Sdílené tabulky + tenant_id | Logická | Nízké | Hodně menších klientů |
| Oddělená schémata | Střední | Střední | Střední počet klientů |
| Oddělené databáze | Fyzická | Vysoké | Málo velkých klientů s citlivými daty |
Jak funguje izolace přes tenant_id
Nejčastější model je sdílená databáze s tenant_id. Každý řádek v každé tabulce nese informaci, kterému klientovi patří. Aby se data nepomíchala, řeší se to na dvou vrstvách najednou.
První vrstva je aplikační: každý dotaz povinně filtruje podle tenant_id. Druhá, kritická vrstva je přímo v databázi přes pravidla přístupu (row level security). Ta zajistí, že i kdyby v aplikaci vznikla chyba, databáze sama nepustí klientovi cizí řádky:
-- Pravidlo: klient vidí jen svoje řádky
CREATE POLICY tenant_isolation ON objednavky
USING (tenant_id = current_tenant_id());Tomuhle dvojitému jištění se říká obrana do hloubky. Když selže jedna vrstva, druhá data ochrání. Detail, jak row level security funguje, rozebírám v článku row level security vysvětleno.
Jak aplikace pozná, o kterého klienta jde
Když přijde požadavek na webu klienta-novak.cz, aplikace musí poznat, že jde o tenanta Novák. Řeší to vrstva, která se dívá na doménu nebo subdoménu v příchozím požadavku, podle ní najde správného tenanta a jeho id pak protáhne celým zpracováním. Od té chvíle aplikace ví, čí data má servírovat, jaký vzhled nasadit a jaké funkce má klient zaplacené.
Funkce na míru bez větvení kódu
Krása multi-tenant systému je, že rozdíly mezi klienty neřešíš v kódu, ale v datech. Jeden klient má zaplacený rezervační modul, druhý ne. Jeden chce oranžovou, druhý modrou. Místo abys pro každého psal vlastní verzi, máš v databázi přepínače funkcí (feature flags) a nastavení vzhledu, které aplikace při běhu načte podle tenanta.
Výsledek je, že jeden codebase obslouží klienty s úplně jinou nabídkou i vizuálem. Když chceš novému klientovi něco zapnout, jen překlikneš hodnotu v databázi, žádné nasazování. Tahle flexibilita je přesně to, proč multi-tenant dává smysl: spravuješ jedno, prodáváš mnohé.
Kde jsou skutečná rizika
Multi-tenant zní jako samá výhra, ale má dvě tvrdá rizika, která musíš brát vážně:
- Únik dat mezi klienty. Jediná chyba ve filtrování může odhalit data jednoho klienta druhému. Proto ta dvojitá obrana a důsledné testování izolace.
- Sdílený bod selhání. Když spadne sdílená databáze, spadnou všichni klienti najednou. U single-tenant by vypadl jen jeden. To vyžaduje robustní zálohy, monitoring a plán obnovy.
Sám jsem si na tohle dával velký pozor, když jsem stavěl svoji platformu, na které běží více webů z jednoho kódu. Izolaci dat jsem testoval znovu a znovu, protože tady se chyba neodpouští.
Co tím získáš
Když je multi-tenant postavený dobře, výhody jsou obrovské. Jednu opravu nasadíš všem. Nového klienta spustíš za pár minut bez psaní kódu. Provozní náklady na klienta klesají, protože infrastrukturu sdílíš. A vývoj se soustředí na jeden codebase místo desítek. Přesně tahle ekonomika dělá ze SaaS produktů škálovatelný byznys.
Onboarding nového klienta v praxi
U dobře postaveného multi-tenant systému je naskočení nového klienta otázka minut, ne dní. Vytvoříš záznam tenanta, přiřadíš mu doménu, zapneš funkce, které si platí, a pozveš jeho administrátora. Žádné kopírování kódu, žádné nasazování zvlášť. Klient se přihlásí a začne si plnit obsah sám přes administraci, aniž by se ho kdokoliv dotkl na úrovni kódu.
Tahle rychlost je obchodní výhoda. Když umíš spustit klienta během dopoledne, můžeš jich obsloužit desítky bez toho, abys najímal armádu lidí. Náklady na získání dalšího klienta klesají k nule a tvoje marže roste s každým novým webem na platformě.
Časté dotazy
Je sdílená databáze bezpečná pro citlivá data?
Může být, pokud je izolace postavená na dvou vrstvách a důsledně testovaná. U extrémně citlivých dat (zdravotnictví, finance) ale klienti často vyžadují fyzicky oddělenou databázi, a to je legitimní volba navzdory vyšším nákladům.
Kdy se multi-tenant nevyplatí?
Když máš jen pár velkých klientů s velmi rozdílnými požadavky nebo přísnými regulacemi na oddělení dat. Tehdy bývá jednodušší a bezpečnější jet oddělené instance.
Jak řeším různý vzhled pro každého klienta?
Vzhled, barvy, fonty a obsah se ukládají jako data klienta v databázi, ne natvrdo v kódu. Aplikace je při běhu načte podle tenanta. Jeden kód tak umí vykreslit desítky vizuálně úplně odlišných webů.
Chceš vlastní platformu
Multi-tenant architektura je páteří každého SaaS produktu i agentury, která chce provozovat weby pro mnoho klientů efektivně. Postavit ji bezpečně, s pořádnou izolací dat, je ale řemeslo, kde se chyby platí draho. Přesně tohle stavím a provozuju. Pokud uvažuješ o aplikaci, ze které chceš obsloužit mnoho klientů, ozvi se přes kontakt a navrhnu ti řešení na míru.