You are reviewing a design for an internal tool with 200 users. It proposes Kubernetes, microservices, Kafka, a service mesh and CQRS. How do you handle the review?
Show the full answer Hide the answer
What the interviewer is testing
Judgement, and whether you can push back without alienating a team. Anyone can spot over-engineering; the question is what you do about it.
The assessment
For 200 internal users, the proposal is roughly two orders of magnitude more machinery than the problem needs. Each element carries a cost the team will pay every week:
| Proposed | Cost | Likely right answer |
|---|---|---|
| Kubernetes | Cluster operation, upgrades, a new failure domain | A managed container service, or a VM |
| Microservices | Network failure modes, distributed debugging, no transactions | A modular monolith |
| Kafka | Operating a broker, or the bill for a managed one | The database, or a simple queue |
| Service mesh | Sidecar overhead, certificate lifecycle, opaque failures | TLS at the ingress |
| CQRS | Two models, eventual consistency in the UI | One model |
The load is trivial. The team is presumably small. Every one of these choices adds an operational burden that will be carried by the same people, forever, in exchange for scaling properties that will never be exercised.
How to run the review
Start by asking, not telling. "What is driving the Kafka decision?" Sometimes there is a constraint you do not know — an existing platform standard, a genuine integration requirement, a compliance rule. Opening with a verdict guarantees a defensive conversation and you lose the information.
Make the cost concrete, not abstract. Not "this is over-engineered" but "who upgrades the cluster, and what happens to this tool during that upgrade?" and "when this pages at 2 AM, which of the six components does the on-call engineer look at first?" Operational questions land where architectural opinions do not.
Anchor on the requirements. 200 users, known load, internal audience. Ask which requirement each component satisfies. The ones with no answer remove themselves without you having to argue.
Offer the alternative in full. "A modular monolith on a managed container service with Postgres — here is how it handles each of your requirements, here is what we would change if it grows." Criticism without a concrete alternative reads as obstruction.
Distinguish reversible from irreversible. If the team wants Kubernetes because they want to learn it, and the organisation already runs clusters, that may be an acceptable price for engagement. Microservice boundaries and CQRS are much harder to undo and deserve a firmer line.
Leave a route to yes. Name the condition under which each component would be right, so the decision is deferred rather than denied.
What a strong answer adds
Acknowledging the legitimate motivations underneath — career development, wanting the CV line, believing that starting simple means rewriting later — and addressing them directly rather than pretending they are not there. And noting that "we can extract services later from a well-modularised monolith" is not a consolation, it is the better engineering path.