When would you choose microservices over a monolith?
Reported in BlaBlaCar European engineering loops. Architecture trade-off question for mid-level backend and platform roles.
Interview scenario
Often asked in BlaBlaCar loops at European offices (London, Berlin, Amsterdam, Paris, Stockholm, Dublin, and remote EU). Prepare a clear spoken answer plus key trade-offs.
Model answer
Try answering aloud first
Cover trade-offs, structure, and a concrete example before revealing the baseline response.
How to frame this at BlaBlaCar: Connect your answer to measurable impact, clarity of thought, and trade-offs the team cares about. Below is a strong baseline response you can adapt with your own project examples.
Start with monolith advantages: simpler deploy, debug, and transaction boundaries (ACID in one DB). Best for early products and small teams when domain boundaries are unclear.
Microservices help when independent scaling, team autonomy, polyglot stacks, or fault isolation justify operational cost. Example: checkout must scale separately from catalog; deploy payments without risking search.
Costs of microservices: network latency, distributed tracing, eventual consistency, deployment pipelines per service, and organizational overhead (Conway's law).
Pragmatic path: modular monolith first, extract services when pain is measured—not speculative. Mention API gateway, service mesh, saga pattern for distributed transactions, and observability (metrics, logs, traces) as prerequisites.
Discussion
Comments (0)
Share how this question came up in your loop, or add tips for others preparing.
Log in to comment on this question.