Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Monolith or microservices for a new product?

They're testing: judgement over fashion.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Start with a modular monolith: simpler to build, deploy and debug, with in-process calls and real transactions, while the domain is still being learned. Enforce module boundaries so pieces can be extracted later. Split out services when there's a named reason: team contention, very different scaling, isolation or compliance needs.
3
4**Counter-questions:**
5- *"What if you expect massive scale?"* → A monolith scales horizontally too; extract the hot parts when they're actually hot.
6
7**Trap:** "microservices from day one because it scales".

Q2. What are the downsides of microservices?

They're testing: honesty about costs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Network latency and partial failure on every call; availability multiplies down across chains; no simple transactions or joins across services; more operational load per service (pipelines, monitoring, on-call); harder debugging needing tracing; and the risk of a distributed monolith where services are tightly coupled anyway.
3
4**Counter-questions:**
5- *"Real example?"* → Prime Video's 2023 write-up: moving a distributed monitoring service into one process cut its cost by 90%.
6
7**Trap:** listing only benefits.

Q3. What is a modular monolith?

They're testing: knowing the middle ground.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** One deployable application split into modules with explicit public interfaces, declared dependency directions and owned tables, enforced by tooling. It gives clear ownership and low coupling without network costs, and makes extracting a service later straightforward. Shopify is a well-known example.
3
4**Counter-questions:**
5- *"How do you enforce boundaries?"* → Dependency checks in CI, package visibility rules, and module-owned schemas.
6
7**Trap:** describing it as "a monolith with folders".

Q4. How do you decide service boundaries?

They're testing: design thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** By business capability or bounded context, keeping things that change together and communicate heavily in the same service, and cutting where communication is light. Avoid splitting by technical layer or by table. Watch for warning signs: services that always deploy together, chatty calls, features spanning many services.
3
4**Counter-questions:**
5- *"How do you fix a wrong boundary?"* → Merge services back, or move the capability; it's cheaper than living with constant cross-service changes.
6
7**Trap:** one service per database table.

Q5. How do services find each other?

They're testing: infrastructure basics.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Through service discovery: instances register with a registry and heartbeat; callers look up a service name and pick a healthy instance (client-side), or call a stable name that a load balancer resolves (server-side). Kubernetes Services and DNS, Consul and Eureka are common; a service mesh can handle discovery, retries and mTLS in sidecars.
3
4**Counter-questions:**
5- *"What if the registry is down?"* → Clients cache the last known instances; registries are replicated.
6
7**Trap:** hard-coded IPs.

Q6. Should each microservice have its own database?

They're testing: data ownership.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Yes, logically: each service is the only writer and direct reader of its data, so it can change its schema and store independently. Others use its API or events. Costs: no cross-service joins (use API composition or local copies kept by events) and no cross-service transactions (use sagas and outboxes).
3
4**Counter-questions:**
5- *"Can they share a physical server?"* → Yes, with separate schemas and credentials; the rule is ownership, not hardware.
6
7**Trap:** a shared database "for convenience".

Q7. Sync or async communication between services?

They're testing: coupling awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Sync when the caller needs the answer to continue (stock check, payment), with timeouts and fallbacks, and short chains. Async via events or queues for side effects that can happen later (emails, points, indexing), which decouples availability and lets new consumers subscribe.
3
4**Counter-questions:**
5- *"Downside of async?"* → Eventual consistency, harder tracing, duplicate and ordering handling.
6
7**Trap:** long synchronous chains for everything.

Q8. What is a distributed monolith?

They're testing: recognising a common failure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Services that are separately deployed but tightly coupled: they must release together, share a database, or call each other synchronously in long chains, so one failure or change ripples everywhere. You pay all the costs of distribution without independence. Fix by redrawing boundaries, moving to events, and giving services their own data.
3
4**Counter-questions:**
5- *"How do you spot it?"* → Coordinated releases, shared schemas, and incidents that always involve many services.
6
7**Trap:** counting services as a measure of success.

Q9. How would you migrate a monolith to microservices?

They're testing: practical execution.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Modularise inside the monolith first. Then extract one well-bounded capability at a time with the strangler fig pattern: route traffic for that capability to the new service through a facade, move its data with dual writes or CDC, then retire the old code. Build the platform (CI/CD, observability, discovery) first, and measure deploy frequency and incidents.
3
4**Counter-questions:**
5- *"What do you extract first?"* → Something valuable and well-bounded with few dependencies, like notifications, search or payments.
6
7**Trap:** a big-bang rewrite.

Q10. A slow downstream service brings your service down. Why, and what do you do?

They're testing: failure propagation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Without timeouts, every request waits on the slow dependency and holds a thread or connection; by Little's law, in-flight requests pile up until the pool is exhausted and the service stops responding to everything. Add timeouts, circuit breakers, bulkheads (separate pools per dependency), fallbacks like cached data, batched calls, and make non-critical calls async (Chapter 29).
3
4**Counter-questions:**
5- *"How do you pick the timeout?"* → From the dependency's normal p99 plus a margin, within the caller's own latency budget.
6
7**Trap:** "add more threads".
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 27.1 Monolith | Level 1A.1, Level 1B.1, Q1 |
18| 27.2 Monolith strengths | Level 1A.1, Q1 |
19| 27.3 Modular monolith | Level 1A.3, Level 3.2, Q3 |
20| 27.4 Microservices | Level 1A.2, Level 1A.4, Q2 |
21| 27.5 Real cost | Level 2.1, Level 2.2, Level 3.1, Q2, Q8 |
22| 27.6 Boundaries | Level 1B.3, Level 2.4, Level 3.3, Q4 |
23| 27.7 Service discovery | Level 3.4, Level 5.3, Q5 |
24| 27.8 Sync vs async | Level 1B.5, Level 2.5, Level 3.5, Level 4, Q7, Q10 |
25| 27.9 Database per service | Level 1B.2, Level 1B.4, Level 2.3, Level 5.4, Q6 |
26| 27.10 When to split | Level 5.1, Level 5.2, Level 5.5, Q9 |
27
28---

27. Monolith vs Microservices