Otázky na Pohovoru o Mikroslužbách

Přečetli jste si názvy vzorů, umíte odrecitovat, co dělá circuit breaker, a přesto nevíte, co panel poslouchá. Tato část pojmenovává čtyři oblasti, které tazatelé hodnotí, v pořadí, v jakém je obvykle zkoumají. Každá je hodnotící otázkou převlečenou za otázku ze slovníku.

• Dekompozice. Kde řežete a proč zrovna tam? Tazatelé chtějí hranici vedenou podél obchodní schopnosti nebo vlastnictví dat, ne podél technických vrstev.
• Komunikace. Synchronní požadavek/odpověď nebo asynchronní eventy, a co se v každém případě rozbije. Požadovaná odpověď je kompromis, ne preference.
• Data. Jedna databáze na službu znamená žádné joiny mezi službami a žádnou distribuovanou transakci. Jak přesto udržíte systém správný?
• Provoz. Deployment, verzování, trasování, a co se stane ve tři ráno, když je jedna služba pomalá, ne spadlá.

Všimněte si, že nic z toho se netýká frameworku. Kandidát, který vysvětlí, proč oddělil checkout od inventory, vždy bodově porazí toho, kdo jen vyjmenuje anotace.

Toto jsou otázky, kterými začíná většina kol o mikroslužbách, spolu s tím, co tazatel u každé skutečně ověřuje.

• Jak byste rozdělili tento monolit na služby? Ověřuje, zda řežete podél obchodních schopností a vlastnictví dat, nebo podél vrstev controller, service a repository. Druhá odpověď vytváří distribuovaný monolit.
• Jak spolu komunikují dvě služby? Ověřuje, zda dokážete pojmenovat cenu každé volby: synchronní volání dávají jednoduchý mentální model, ale spojují dostupnost, asynchronní eventy dostupnost oddělují a dávají eventual consistency, kterou musíte vysvětlit product ownerovi.
• Co je distribuovaný monolit a jak se mu vyhnout? Ověřuje, zda víte, že služby, které musí být nasazovány společně, ve skutečnosti nejsou oddělené.
• Jak velká by měla být služba? Ověřuje, zda odoláte pokušení uvést číslo. Velikost sleduje hranici a tým, který ji vlastní.
• Potřebujete API gateway a co dělá? Ověřuje, zda dokážete oddělit routing, autentizaci a rate limiting od obchodní logiky.
• Jak se služby navzájem nacházejí? Ověřuje základní znalost service discovery a proč natvrdo zakódované hosty selhávají ve škálovaném prostředí.

Řekněte kompromis nahlas v každé odpovědi. Panel nemůže dát body za srovnání, které jste udělali potichu v hlavě.

Tady se pohovory vyhrávají nebo prohrávají, protože tyto otázky nemají čistou odpověď a kandidáti sahají po naučené odpovědi.

• Jak udržujete konzistenci dat napříč službami? Nejprve pojmenujte omezení: neexistuje transakce mezi službami. Pak popište sagu, buď choreografovanou přes eventy, nebo orchestrovanou koordinátorem, a řekněte jasně, že systém je eventually consistent a co uživatel vidí v tom intervalu.
• Co se stane, když je downstream služba pomalá? Timeouty, retry s backoffem, a circuit breaker, aby pomalá závislost nevyčerpala váš thread pool. Pomalé je horší než spadlé, a říct to signalizuje produkční zkušenost.
• Jak udělat retry bezpečný? Idempotency. Idempotency key na cestě zápisu, aby se opakovaná platba strhla jen jednou.
• Jak řešíte částečný výpadek ve vícekrokovém toku? Kompenzační akce, ne rollback. Vysvětlete, jak vypadá vrácení peněz nebo uvolnění rezervace.
• Jak ladíte požadavek, který se dotkl šesti služeb? Distributed tracing s correlation ID šířeným přes každý hop, plus strukturované logy a metriky.

Backend inženýr, který dělal pohovor na roli platform L5 u veřejného cloudového poskytovatele, dostal otázku o saze a odpověděl na ni najednou, slovníkem vzorů, aniž by jednou zmínil, co by viděl zákazník. Doplňující otázka, co ukazuje stránka objednávky během nekonzistentního okna, je otázka, která ve skutečnosti rozhoduje kolo. Připravte druhou odpověď, ne jen tu první.

Více bank otázek podle role a tématu je shromážděno pod otázkami na pohovor podle role.

Čtení tohoto seznamu vyvolává pocit rozpoznání, a ten pocit zmizí, jakmile se zeptá cizí člověk a čeká. Propast mezi znalostí vzoru a jeho vysvětlením pod mírným tlakem je celá obtížnost kola system design, a zavírá se jen mluvením.

Vyberte si jeden tok, který dobře znáte, zadání objednávky nebo registraci, a vyprávějte nahlas celou dekompozici: hranici, volbu komunikace, příběh konzistence, příběh výpadku. Dělejte to, dokud nepřestanete začínat věty znovu. Tyto prompty si můžete vyzkoušet proti AI tazateli, který klade doplňující otázky a nechá vás odpovídat hlasem v režimu simulovaného pohovoru, což je mnohem blíž realitě než přečítání poznámek.

Aaron Cao, zakladatel SubcueAI, postavil režim procvičování kolem právě této propasti, ne kolem doručování obsahu. Seznamy otázek jsou volně dostupné všude; co kandidátům chybí, jsou opakování vyslovení odpovědi, zatímco někdo čeká. Během skutečného pohovoru mohou desktopová aplikace a Side Panel rozšíření prohlížeče zobrazovat strukturované prompty, zatímco tazatel mluví, i když natrénované vysvětlení vždy porazí to, které čtete poprvé. Co asistent dělá a nedělá, je popsáno na přehledu produktu.