Revision and Interview Questions

Cheat sheet

Monolith: one deployable unit; simple development, testing, deployment and transactions; scales horizontally if stateless; the problem is the ball of mud, not the monolith. Microservices: independently deployable services around business capabilities, owning their data, owned by one team; benefits are mostly organisational (autonomy, independent releases) plus independent scaling and fault isolation, at the cost of the distributed systems tax. Spectrum: ball of mud → modular monolith → SOA → microservices → serverless; Conway's law and the inverse Conway manoeuvre. Deciding: monolith first for small teams and unclear domains; extract for named reasons. Modular monolith: modules with public APIs, enforced dependencies, schema per module. Boundaries: bounded contexts, capabilities, high cohesion, low coupling; avoid entity and nano-services. Data: database per service; API composition, event-carried copies, CQRS; sagas, outbox, idempotency. Communication: sync vs async; backward-compatible contracts; contract tests. Infrastructure: gateway, BFF, discovery, mesh, per-service pipelines, platform team. Migration: strangler fig, branch by abstraction, parallel run, data last; merging back is valid.

Common interview questions

Answer each with a trade-off and an example.

1. What is a monolith, and what are its real advantages?
2. Define microservices. Why is independent deployability the key property?
3. What is a modular monolith and how do you enforce its boundaries?
4. How do you find good service boundaries? What are entity services?
5. Why is a shared database an anti-pattern, and how do you query across services?
6. How do you keep data consistent without distributed transactions?
7. API gateway vs BFF vs service mesh: what does each do?
8. Explain the strangler fig pattern and how you would extract one service.
9. What is a distributed monolith, and how do you recognise one?
10. When would you merge microservices back together?

Avoid dogma in interviews

Strong answers start with "it depends on" followed by concrete factors: team size, domain clarity, scaling needs and operational maturity. Then commit to a recommendation for the scenario given.

त्वरित जाँच: A company has two engineers and an unproven product. An interviewer asks which architecture to start with. What is the strongest answer?

• Microservices from day one so it can scale later
• Serverless functions for every endpoint without exception
• A service per database table
• A modular monolith, extracting services later when specific pressures appear