# Revision and Interview Questions — Monolith vs Microservices

Source: https://www.skillbyai.com/en/monolith-microservices/p-revision

> Recall the key ideas for exams and system design interviews.

## 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.

```text
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.

**Quiz:** 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
- [x] A modular monolith, extracting services later when specific pressures appear

*Answer:* A modular monolith, extracting services later when specific pressures appear. A modular monolith keeps change cheap now while preserving clean seams for later extraction.