System Design: jak projít pohovor

System Design v pohovorech: struktura přístupu a typické chyby

System Design posuzuje schopnost navrhovat škálovatelné systémy. Pro začátek stačí zvládnout klíčové koncepty: Load Balancer pro rozdělování provozu, Sharding a Partitioning pro horizontální škálování, Replikace pro dostupnost dat, Message Queue pro asynchronní zpracování. Prostudujte typy databází — relační a NoSQL — s ohledem na jejich datové struktury (B-Tree v SQL, LSM-tree v NoSQL). Za 2 týdny denního čtení po jednom tématu denně se vytvoří dostatečný základ pro pohovory ve středních společnostech.

Typické úkoly a struktura pohovoru

Úkoly se zaměřují na backend: navrhnout sociální síť s novinovou osou, videohosting nebo mapovou službu. Frontend System Design se vyskytuje méně často, jen na frontendových pozicích. Backend se kontroluje vždy.

Pohovor začíná popisem služby a požadavků. Prvních 5 minut věnujte objasnění:

• Funkční požadavky (funkce: vyhledávání kaváren na mapě, plánování tras).
• Nefunkční požadavky (škálování: QPS, objem dat; spolehlivost, bezpečnost, latence).

Nepřecházejte k diagramu hned — to je častá chyba. Bez objasnění riskujete navrhování zbytečného a ztrátu času.

Volba architektonických řešení: Push vs Pull

Rozlišujte modely interakce služeb:

• Push: zdroj (A) upozorní příjemce (B) po dokončení úkolu.
• Pull: příjemce (B) pravidelně dotazuje zdroj (A).

| Model | Výhody | Nevýhody |

|--------|-------------|------------|

| Push | Nízká latence, okamžité upozornění | Riziko přetížení příjemce, složitost při výpadcích |

| Pull | Kontrola zátěže, jednoduchá odolnost vůči chybám | Zpoždění kvůli dotazování, zvýšený provoz |

Příklady: Prometheus používá Pull pro metriky, InfluxDB — Push. Volba závisí na scénáři: Push pro real-time, Pull pro dávkové zpracování.

Message Brokers vs Batch Jobs

Pro rozdělení zátěže porovnávejte:

• Message Queues (Kafka, RabbitMQ): asynchronní zpracování, rovnoměrné rozdělení, nízké latence.
• Batch Jobs (Cron, Airflow): spouštění podle plánu, vhodné pro analytiku nebo ETL úkoly s pevným časem.

Chyba: ignorovat batch pro úkoly podnikání vyžadující noční zpracování (reporty). Queues jsou lepší pro špičkové zatížení, jobs — pro předvídatelné.

Kompromisy v návrhu systémů

Každé rozhodnutí nese ústupky:

• Monolit vs Mikroslužby: monolit je rychlejší ve vývoji a nasazení, mikroslužby jsou škálovatelné, ale zvyšují latenci a složitost síťové komunikace.
• SQL vs NoSQL: SQL zaručuje ACID a JOINy, NoSQL — horizontální sharding a schéma bez migrací.

Chápejte ztráty:

• Škálovatelnost se obětuje rychlosti vývoje.
• Datové schéma zjednodušuje dotazy, ale komplikuje vývoj.

Senior inženýři zdůvodňují volbu kompromisy, ne zkušenostmi "utrpěl na projektu".

Doporučené materiály

• System Design Interview Vol. 1 (Alex Xu): Základ + populární úkoly (novinová osa, YouTube). Ideální start, rovnováha teorie a praxe.
• System Design Interview Vol. 2 (Alex Xu): Hlouběji v kompromisech, méně standardní případy.
• Designing Data-Intensive Applications (Martin Kleppmann): Datové struktury, problémy distribuovaných systémů (CAP teorém, konzistence). Pro Principal úroveň, čtěte po základech.

Označujte klíčová místa, ohýbejte stránky pro opakování.

Co je důležité

• Objasňujte požadavky 5 minut na začátku — vyhněte se navrhování zbytečného.
• Zdůvodňujte volbu (queues vs jobs, push vs pull) kompromisy, ne preferencemi.
• Zaměřujte se na kompromisy: neexistují ideální řešení.
• Osvojte si základy za 2 týdny, prohlubujte znalosti knihami pro Big Tech.
• Cvičte na skutečných úkolech z knih Xu.

System Design odhaluje 'kouzlo' služeb jako S3 nebo platební systémy a rozvíjí schopnost vyvážených rozhodnutí.

— Editorial Team