Jedna z nejcennějších dovedností zkušeného backend engineera není psát kód, ale vybrat správný nástroj a umět obhájit proč — a stejně tak odmítnout nástroj, který je sice populární, ale na tenhle problém se nehodí. Většina architektonických katastrof totiž nevzniká špatně napsaným kódem, ale špatně zvolenou technologií. Tahle kapitola tě naučí o volbách přemýšlet.
Pár pojmů na úvod
- Provozní náklad = kolik práce dá technologii dlouhodobě provozovat: naučit se ji, monitorovat, aktualizovat, opravovat, najít na ni lidi. Nová technologie nikdy není „zadarmo".
- Throughput (průtok) = kolik toho nástroj zvládne za jednotku času (např. zpráv za sekundu).
- Lock-in = uvíznutí u dodavatele nebo technologie, ze které se pak těžko přechází jinam.
- Škála (scale) = jak velký provoz/objem dat musíš zvládnout.
Zlaté pravidlo: nudná technologie vyhrává
Choose Boring Technology („vybírej nudné technologie"). Každá nová technologie má skrytý provozní náklad. Máš jen omezený „rozpočet na inovaci" — utrať ho tam, kde je to tvoje konkurenční výhoda, ne na infrastruktuře, kterou má vyřešenou kdekdo.
- Postgres + jeden monolit + jeden server uvezou překvapivě velký provoz. Většina firem Kafku, Kubernetes ani microservices nepotřebuje — nasadí je z módy a zaplatí to složitostí.
- YAGNI (You Aren't Gonna Need It — „nebudeš to potřebovat") — neřeš škálu, kterou nemáš. Předčasná složitá architektura tě zabije dřív než úspěch.
Anti-patterny výběru (poznej je i u sebe)
- 🚩 Resume-driven development — vybírám podle toho, co chci mít v životopise, ne podle toho, co řeší problém.
- 🚩 Hype-driven — „všichni dělají microservices/Kafku/Mongo, tak my taky".
- 🚩 Big-tech cargo cult — „Netflix to dělá takhle". Jenže ty nejsi Netflix a nemáš jeho škálu ani stovky lidí na provoz.
- 🚩 Golden hammer („zlaté kladivo") — umím jeden nástroj, tak ho cpu na všechno.
- 🚩 Shiny new thing — nezralá novinka bez komunity = ty jsi její testovací oddělení.
Rozhodovací postup (projdi ho pokaždé)
Než nasadíš jakoukoli technologii, zodpověz si:
- Jaký konkrétní problém řeší? Pojmenuj ho. Když to nedokážeš, nástroj nepotřebuješ.
- Co je nejjednodušší věc, která by fungovala? Začni od ní (soubor? tabulka v Postgresu? cron?).
- Mám ten problém opravdu teď? Nebo „možná za dva roky při 100× provozu"? → YAGNI.
- Jaký je provozní náklad? Kdo to bude provozovat, hlídat a opravovat ve 3 ráno?
- Je to zralé a má to komunitu? Stabilní verze? Dokumentace? Najdu na to lidi a odpovědi?
- Jak se to spojí s tím, co už mám? Každá další databáze = další záloha a další věc, co se rozbije.
- Jak z toho ven? Jak těžké bude to za dva roky vyměnit (lock-in)?
Dobrá obhajoba zní: „Mám problém X, nejjednodušší řešení je A, ale naráží na konkrétní limit L, proto sahám po B a beru na sebe náklad N." Špatná zní: „B je moderní / rychlé / cool."
Konkrétní volby
Jazyk / runtime
Nejde o „nejrychlejší", ale o vhodnost + ekosystém + tým.
- Node / TypeScript — skvělý na I/O práci (API, realtime), sdílí jazyk s frontendem, obří ekosystém knihoven.
- Go — jednoduchost a výkon, ideální na síťové služby a infra nástroje; snadné nasazení (jedna binárka).
- Python — data, ML, skripty, rychlý vývoj; pomalejší běh.
- Java / C# — velký enterprise, zralé a výkonné, ale upovídané.
- Rust — maximální výkon a bezpečnost paměti tam, kde záleží na každé mikrosekundě; pomalejší vývoj.
Rozhoduj: Je problém spíš o čekání (I/O), nebo o počítání (CPU)? Co umí tým? Jaké knihovny potřebuju?
Pozn.: porovnání konkrétních možností (databáze, broker, API styl, architektura, hosting) najdeš v tabulkách níže — tady je jen princip, jak se rozhodnout. Záměrně to neopakuju dvakrát.
SQL vs NoSQL — a KTERÁ
Výchozí volba = Postgres (zvládne relace, JSON, fulltext… jeden nástroj na 90 % potřeb). Po jiné databázi sáhni jen s konkrétním limitem, který Postgres neuveze. Pravidlo: jedna databáze, dokud tě limit nedonutí přidat druhou — každá další je další záloha, monitoring a věc, co se může rozejít.
Message broker — Kafka vs RabbitMQ vs nic
Nejdřív se zeptej: potřebuju vůbec broker? Na pár asynchronních úloh stačí tabulka v Postgresu jako fronta nebo Redis; broker přidej, až to přeroste. 🚩 „Nasadíme Kafku" bez odpovědi na jaký průtok a proč ne tabulka v Postgresu = červená vlajka.
Monolit vs Microservices ⭐ (nejdražší rozhodnutí)
Začni monolitem. Skoro vždy — jednodušší vývoj, nasazení, debug i transakce, žádná síťová režie. Microservices řeší organizační, ne technický problém (víc týmů, co se nechtějí blokovat; části s různými nároky na škálu) a platíš za ně daň: distribuované transakce (saga!), výpadky sítě, eventual consistency, složitější provoz. Cesta: dobře rozčleněný monolit → vyřízni z něj službu, teprve až to reálně bolí.
Hosting / cloud
Začni jednoduše — jeden server nebo PaaS (Railway, Render, Fly, Coolify); vydrží to déle, než čekáš. Kubernetes ber, až máš mnoho služeb a tým, který ho uveze (pro malý projekt provozní peklo). Serverless na nepravidelný provoz (pozor na cold start a lock-in). A managed vs vlastní provoz: managed stojí víc peněz, ale šetří tvůj čas a noční pohotovosti.
📊 Rozhodovací tabulky (kus po kuse)
Rychlá reference. Sloupec „Sáhni po tom, když" je důležitější než výčet vlastností — rozhoduj se podle problému, ne podle počtu ✅.
Databáze — kterou jako hlavní
| Postgres | MySQL | MongoDB | Redis | Cassandra/Dynamo | Elasticsearch | |
|---|---|---|---|---|---|---|
| Model | Relační + JSON | Relační | Dokumentový | Klíč-hodnota | Wide-column | Vyhledávací index |
| Transakce | ✅ silné ACID | ✅ ACID | ⚠️ omezené | ⚠️ základní | ❌ (eventual) | ❌ |
| JOINy | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Škála zápisu | Silnější stroj + sharding | Silnější stroj | Horizontální | Silnější stroj | Horizontální ⭐ | Horizontální |
| Latence | ms | ms | ms | zlomky ms ⭐ | ms | ms |
| Sáhni po tom, když | Default na 90 % | Máte už MySQL | Hodně proměnlivé schéma, žádné JOINy | Cache, rate limit, fronty | Obří objem zápisů, OK s eventual | Fulltext, logy |
Výchozí volba = Postgres. Ostatní přidávej až s konkrétním limitem, který Postgres neuveze.
Message broker
| Postgres/Redis fronta | RabbitMQ | Kafka | SQS (cloud) | |
|---|---|---|---|---|
| Jak na to myslet | Tabulka úkolů | Chytrá fronta | Trvalý záznam | Spravovaná fronta |
| Průtok | Nízký–střední | Střední–vysoký | Velmi vysoký ⭐ | Vysoký |
| Přehrávání historie | ❌ | ❌ | ✅ ⭐ | ❌ |
| Víc nezávislých konzumentů | ❌ | ⚠️ | ✅ ⭐ | ⚠️ |
| Provozní náklad | ~nula ⭐ | Střední | Vysoký | Nula (managed) |
| Sáhni po tom, když | Pár úloh, malý objem | Úkoly, složité routování | Streaming, přehrávání, velký objem | Jsi v cloudu, nechceš nic provozovat |
🚩 Kafka má smysl od vysokého průtoku / potřeby přehrávání / mnoha konzumentů. Na pár zpráv denně = tabulka v Postgresu.
API styl
| REST | gRPC | GraphQL | |
|---|---|---|---|
| Výkon | Dobrý | Nejlepší ⭐ | Dobrý |
| Typovost | ⚠️ | ✅ ⭐ | ✅ |
| Z prohlížeče napřímo | ✅ | ⚠️ jen přes gRPC-Web/proxy | ✅ |
| Cachování | ✅ snadné ⭐ | ❌ těžké | ❌ těžké |
| Složitost serveru | Nízká | Střední | Vysoká |
| Sáhni po tom, když | Default, veřejné API | Mezi vlastními službami, nízká latence | Mobil / proměnlivé potřeby klienta |
Architektura
| Monolit | Modular monolith | Microservices | |
|---|---|---|---|
| Vývoj/debug | Snadné ⭐ | Snadné | Těžké (distribuované) |
| Transakce | ✅ lokální ⭐ | ✅ lokální | ❌ saga, eventual |
| Nezávislé škálování/deploye | ❌ | ⚠️ | ✅ ⭐ |
| Provozní/síťová režie | Nízká ⭐ | Nízká | Vysoká |
| Sáhni po tom, když | Skoro vždy na startu | Roste, chceš hranice modulů | Víc týmů se blokuje, různé nároky na škálu |
Cesta zleva doprava, až když to bolí. Ne naopak.
Hosting
| 1 server / VPS | PaaS (Railway, Render, Coolify) | Serverless | Kubernetes | |
|---|---|---|---|---|
| Setup | Ruční | Snadný ⭐ | Snadný | Složitý |
| Provozní náklad | Střední | Nízký | Nízký | Vysoký |
| Cena při malém provozu | Fixní | Nízká | ~nula ⭐ | Vysoká |
| Sáhni po tom, když | Plná kontrola | Default pro malé/střední | Nepravidelný provoz | Mnoho služeb + tým na k8s |
🌳 Rychlý rozhodovací strom
Strom je start, ne dogma. Vždy ještě projdi rozhodovací postup výše a obhaj volbu konkrétním problémem.
Jak rozhodnutí zaznamenat (ADR)
Důležitá rozhodnutí si zapiš do krátkého dokumentu: kontext → zvažované možnosti → rozhodnutí →
důsledky. Tomu se říká ADR (Architecture Decision Record). Za rok si nebudeš pamatovat proč, a
nováček to nepřekope naslepo. Jeden .md soubor stačí:
# ADR-001: Postgres jako hlavní databáze
Kontext: Potřebujeme relační data + občas JSON, malý provoz.
Možnosti: Postgres / MongoDB / MySQL.
Rozhodnutí: Postgres — relace i JSON pokryje obojí a tým ho zná.
Důsledky: Při extrémním objemu zápisů budeme později řešit repliky/sharding.
Failure modes — nejčastější chyby ve výběru
- Over-engineering — Kafka/Kubernetes/microservices na projekt, co uveze jeden Postgres. Nejčastější.
- Zbytečně moc databází — pět úložišť, pětkrát víc provozní zátěže, nikdo neví, kde co je.
- Hype lock-in — vsadíš na nezralou technologii, komunita vymře a držíš ji sám.
- Under-engineering — opačný extrém: ignoruješ známý limit, který přijde za měsíc.
🛠️ Cvičení
- Obhaj, nebo zamítni. Junior navrhuje Kafku na appku se 100 zprávami denně. Napiš protiargument a co bys použil místo toho.
- Vyber databázi. Pro tři případy — relační data s občasným JSON, bleskově rychlá cache, fulltext nad logy — vyber úložiště a zdůvodni, proč ne (nebo proč ano) Postgres na všechno.
- Monolit, nebo microservices? Pro startup se čtyřmi vývojáři a jasným produktem rozhodni a vyjmenuj, co bys volbou microservices obětoval.
- Napiš ADR. Vyber reálné rozhodnutí (např. fronta: tabulka v Postgresu vs RabbitMQ) a sepiš ho: kontext → možnosti → rozhodnutí → důsledky.
- Poznej anti-pattern. U pěti výroků urči, jestli jde o resume-driven / hype-driven / golden hammer volbu, nebo o legitimní rozhodnutí.
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- Obhaj, nebo zamítni — zamítni: 100 zpráv denně je zlomek QPS, na který je Kafka kanón na vrabce a navíc drahá na provoz. Použij tabulku v Postgresu jako frontu (nebo Redis). Pozor: brokera přidej, až máš konkrétní důvod — vysoký průtok, přehrávání historie nebo víc nezávislých konzumentů.
- Vyber databázi — relační data s občasným JSON → Postgres (umí obojí, default); bleskově rychlá cache → Redis (zlomky ms); fulltext nad logy → Elasticsearch. Pozor: Postgres na všechno nedáš jen proto, že je default — pro cache a fulltext naráží na konkrétní limit (latence, vyhledávací index), a to je legitimní důvod sáhnout po druhém úložišti.
- Monolit, nebo microservices — pro startup se čtyřmi vývojáři a jasným produktem zvol monolit: jednodušší vývoj, nasazení, debug i transakce. Microservices řeší organizační problém (víc týmů, co se blokují), který tu nemáš. Obětoval bys: lokální transakce (nastoupila by saga + eventual consistency), jednoduchý provoz a žádnou síťovou režii. Pozor: cesta k službám až „když to bolí", ne preventivně.
- Napiš ADR — sepiš čtyři části: kontext (jaký problém a v jakém objemu), možnosti (Postgres fronta vs RabbitMQ), rozhodnutí (např. Postgres fronta — malý objem, žádné nové úložiště) a důsledky (při růstu/složitém routování přejdeme na broker). Pozor: drž to krátké a uchovej proč, ne jen co — jeden
.mdstačí. - Poznej anti-pattern — u každého výroku rozhodni podle motivace: „chci to v životopise" = resume-driven, „všichni to dělají / dělá to Netflix" = hype-driven či cargo cult, „umím jen tohle, tak to cpu všude" = golden hammer; pojmenovaný problém + trade-off = legitimní volba. Pozor: legitimitu nedělá technologie, ale jestli za ní stojí konkrétní problém a limit.
🧠 Otázky & odpovědi
Co znamená zásada choose boring technology a proč platí?
Každá nová technologie má skrytý provozní náklad (naučit se ji, provozovat, opravovat ve 3 ráno, najít lidi, aktualizovat). Máš jen omezený rozpočet na inovaci — utrať ho tam, kde je to tvoje konkurenční výhoda, ne na infrastruktuře, kterou má vyřešenou každý. Osvědčený nudný Postgres + monolit uvezou překvapivě velký provoz; exotika se zaplatí složitostí.
Kdy NEnasadit Kafku?
Když pro ni nemáš důvod: vysoký průtok, potřebu přehrávat historii, nebo víc nezávislých konzumentů téhož proudu. Na pár zpráv denně je to kanón na vrabce — a navíc náročný na provoz. Pro málo asynchronních úloh stačí tabulka v Postgresu jako fronta nebo Redis. Brokera přidej, až přerosteš jednodušší řešení.
Proč začít monolitem a kdy teprve microservices?
Monolit je jednodušší na vývoj, nasazení, debug i transakce a nemá síťovou režii — pro start skoro vždy správně. Microservices řeší hlavně organizační problém (víc týmů, které se nechtějí blokovat, různé nároky na škálu), ne technický, a platíš za ně distribuovanými transakcemi, eventual consistency a provozní složitostí. Vyřízni službu z monolitu, teprve až to reálně bolí.
Jaký je dobrý a špatný způsob, jak obhájit volbu technologie?
Dobrý: „mám problém X, nejjednodušší řešení je A, ale naráží na konkrétní limit L, proto sahám po B a beru na sebe náklad N." Špatný: „B je moderní / rychlé / cool / dělá to Netflix." Volba má vycházet z pojmenovaného problému a trade-offů, ne z módy, životopisu nebo napodobování velkých firem.
K čemu je ADR (Architecture Decision Record)?
Je to krátký zápis důležitého rozhodnutí: kontext → zvažované možnosti → rozhodnutí → důsledky. Za rok
si nebudeš pamatovat proč jste to udělali takhle, a nováček to nepřekope naslepo. Jeden .md soubor
stačí. Dělá rozhodnutí dohledatelným a brání tomu, aby se osvědčené volby měnily z neznalosti kontextu.