Mga Tanong sa Microservices Interview

Nabasa mo na ang mga pattern name, kaya mong sabihin nang paulit-ulit kung ano ang ginagawa ng circuit breaker, pero hindi mo pa rin alam kung ano talaga ang hinahanap ng panel. Sa seksyong ito, ipapakilala ang apat na bagay na sinusuri ng interviewer, ayon sa karaniwang pagkakasunod-sunod nila. Bawat isa ay judgment question na nakadamit bilang vocabulary question.

• Decomposition. Saan mo puputulin, at bakit doon? Gusto ng interviewer na nakaguhit ang boundary base sa business capability o data ownership, hindi sa technical layers.
• Communication. Synchronous request/response o asynchronous events, at ano ang masisira sa bawat isa. Tradeoff ang gustong sagot, hindi personal na preference.
• Data. Isang database bawat service ang ibig sabihin, walang cross-service join at walang distributed transaction. Paano mo pa rin mapapanatiling tama ang system?
• Operations. Deployment, versioning, tracing, at ano ang mangyayari kapag alas-tres ng umaga at mabagal, hindi patay, ang isang service.

Pansinin na wala sa mga ito ang tungkol sa isang framework. Ang kandidatong nagpapaliwanag kung bakit hiniwalay niya ang checkout sa inventory ay laging mananalo sa kandidatong naglilista lang ng annotations.

Ito ang mga tanong na kadalasang nagbubukas sa microservices rounds, kasama ang sinusuri talaga ng interviewer sa likod ng bawat isa.

• Paano mo hahatiin ang monolith na ito sa mga service? Sinusuri kung naghihiwalay ka base sa business capabilities at data ownership, o base sa mga layer na controller, service, at repository. Ang pangalawang sagot ay nagreresulta sa distributed monolith.
• Paano nag-uusap ang dalawang service? Sinusuri kung kaya mong sabihin ang gastos ng bawat pagpipilian: ang synchronous calls ay nagbibigay ng simpleng mental model pero pinagsasama ang availability, ang asynchronous events naman ay naghihiwalay ng availability at nagbibigay ng eventual consistency na kailangan mong ipaliwanag sa isang product owner.
• Ano ang distributed monolith at paano ito maiiwasan? Sinusuri kung alam mo na ang mga service na dapat sabay i-deploy ay hindi na talaga hiwalay.
• Gaano dapat kalaki ang isang service? Sinusuri kung tinatanggihan mo ang pagsagot ng isang bilang. Ang laki ay sumusunod sa boundary at sa team na nagmamay-ari nito.
• Kailangan mo ba ng API gateway, at ano ang ginagawa nito? Sinusuri kung kaya mong ihiwalay ang routing, authentication, at rate limiting sa business logic.
• Paano nakikita ng mga service ang isa't isa? Sinusuri ang basic na pagkakaalam sa service discovery at kung bakit nabibigo ang hardcoded hosts sa scaled na environment.

Sabihin nang malakas ang tradeoff sa bawat sagot. Hindi makakapagbigay ng puntos ang panel para sa paghahambing na ginawa mo lang sa isip mo.

Dito karaniwang napapanalo o natatalo ang interview, dahil walang malinis na sagot sa mga tanong na ito at ang mga kandidato ay bumabalik sa isang na-memorya na sagot.

• Paano mo pinapanatiling consistent ang data sa mga service? Banggitin muna ang constraint: walang cross-service transaction. Pagkatapos, ilarawan ang isang saga, choreographed sa pamamagitan ng events o orchestrated ng isang coordinator, at sabihing malinaw na eventually consistent ang system at kung ano ang makikita ng user sa gap na iyon.
• Ano ang mangyayari kapag mabagal ang isang downstream service? Timeouts, retries na may backoff, at circuit breaker para hindi maubos ng mabagal na dependency ang iyong thread pool. Mas malala ang mabagal kaysa patay, at ang pagsasabi nito ay senyales ng production experience.
• Paano mo gagawing safe ang isang retry? Idempotency. Isang idempotency key sa write path, para minsan lang sisingilin ang paulit-ulit na payment.
• Paano mo hinahandle ang partial failure sa isang multi-step flow? Compensating actions, hindi rollback. Ipaliwanag kung ano ang hitsura ng pag-refund o pag-release ng isang reservation.
• Paano mo dine-debug ang isang request na dumaan sa anim na service? Distributed tracing na may correlation ID na dala-dala sa bawat hop, kasama ang structured logs at metrics.

May backend engineer na nag-interview para sa isang L5 platform role sa isang public cloud vendor na natanong ang saga question at sinagot ito nang diretso, sa pattern vocabulary, pero walang binanggit tungkol sa makikita ng customer. Ang follow-up, kung ano ang ipapakita ng order page habang nasa inconsistent window, ang tanong na talagang nagpapasya sa round. Ihanda ang pangalawang sagot, hindi lang ang una.

Maraming karagdagang question bank ayon sa role at topic na nakakalap sa interview questions by role.

Ang pagbabasa ng listahang ito ay nagbibigay ng recognition, at nawawala ang recognition kapag may estrangherong nagtatanong at naghihintay ng sagot. Ang agwat sa pagitan ng pagkaalam sa isang pattern at ang pagpapaliwanag nito sa ilalim ng bahagyang pressure ang buong hirap ng isang system-design round, at napupuno lang ito sa pamamagitan ng pagsasalita.

Pumili ng isang flow na kabisado mo, tulad ng order placement o signup, at ikwento nang malakas ang buong decomposition: ang boundary, ang pagpili sa communication, ang consistency story, at ang failure story. Gawin ito hanggang tumigil ka nang mag-restart ng pangungusap. Puwede mong subukan ang mga prompt na ito laban sa isang AI interviewer na nagtatanong ng follow-up at pinapayagan kang sumagot sa pamamagitan ng boses sa mock interview mode, na mas malapit sa totoong karanasan kumpara sa muling pagbabasa ng notes.

Si Aaron Cao, founder ng SubcueAI, ang gumawa ng practice mode base sa agwat na iyon, hindi base sa content delivery. Malayang makukuha kahit saan ang mga listahan ng tanong; ang kulang sa mga kandidato ay ang paulit-ulit na pagsasabi ng sagot habang may naghihintay. Sa totoong interview, ang desktop app at ang browser extension na Side Panel ay maaaring magpakita ng structured prompts habang nagsasalita ang interviewer, kahit na laging mas mahusay ang isang inensayong paliwanag kaysa sa binabasa mo sa unang pagkakataon. Ano ang ginagawa at hindi ginagawa ng assistant ay inilalarawan sa product overview.