You review a design for an internal tool with 200 users: microservices, Kubernetes, event sourcing, CQRS, multi-region. How do you respond?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can challenge a design without dismissing the team, and whether you can name the specific cost.
The response
Ask what requirement makes each element necessary, with a number. Not as an interrogation — as the question the design should already answer. Most of these will have no requirement behind them.
For 200 internal users:
| Element | Question |
|---|---|
| Microservices | How many teams work on this? If one, what does independent deployment buy? |
| Kubernetes | Who operates the cluster? What does it provide over a managed container service? |
| Event sourcing | What requires a full audit history and temporal reconstruction? |
| CQRS | What read load justifies separating the models? |
| Multi-region | What downtime tolerance does this tool have, and what does an hour cost? |
The cost to name explicitly
The build is not the cost. The cost is the permanent operational surface: more components to run, patch, monitor and understand; slower onboarding; harder debugging; a larger blast radius; and a system that only its authors can operate.
That cost is paid every week by people who did not make the decision, for a tool with 200 users.
The alternative to propose
A modular monolith on a managed platform with a relational database, deployed simply, with clean internal boundaries. It will be faster to build, dramatically cheaper to run, and — the part worth emphasising — easier to change later if a requirement genuinely emerges.
What to concede
Some things should be right early because they are one-way doors: the data model, the security boundaries, and the internal module boundaries. Getting those right is worth effort. Deployment topology is not, and can change cheaply.
What a strong answer adds
Naming why this happens without blaming anyone: teams build the architecture they want to learn or to have on their CV, and the organisation rarely gives them a legitimate route to that. Offering one — a genuine platform problem to work on — is more effective than refusing this design.
Common weak answers
Approving to avoid conflict. Rejecting on the grounds that it is over-engineered without asking what each element is for.