From Correct to Right

2. The Constraints That Actually Decide

Five constraints do most of the work, and each is usually missing from design discussions until it is too late.

• Team size. Every service, store and pipeline needs somebody who understands it well enough to debug it at an inconvenient hour. Dividing your engineers by your systems gives a number. When that number drops below roughly one engineer per system, you have built something the team cannot operate.
• Timeline. A design that takes three quarters is the wrong design for a product that needs to exist this quarter. Shipping late is a real failure mode, and it rarely appears on an architecture diagram.
• Operational capacity. Not how many engineers, but how much attention they have spare. A team already carrying an on-call rotation and a migration cannot absorb a new datastore, whatever its merits.
• Budget. Both infrastructure spend and the cost of engineer time. A design that saves infrastructure money and costs two engineer-quarters to build has to be weighed, not assumed.
• The system that already exists. Almost nothing starts from nothing. A design that is better in isolation and requires rewriting something that works is competing against leaving that thing alone, which is cheap and safe.

Name at least two of these out loud before you propose an architecture. A design offered without its constraints is being offered as though it were free.

3. The Five-Engineer Variant

Small teams are not scaled-down large teams. Some things are different, not just smaller, and this is where most system design advice fits worst. What changes with five engineers:

• Every system is somebody's second job. Nobody owns one thing. The practical ceiling is roughly three to four distinct systems in production, counting datastores, and past that something is always unattended.
• On-call is everybody. With five people the rotation is at most one week in five, which means every engineer must be able to debug every system. That is a hard constraint on how many different technologies you may use. It is also a stronger argument for boring choices than any technical comparison.
• Nobody is a specialist. There is no database engineer, no platform team, no security function. Anything that needs regular expert attention will go unattended most of the time.
• A migration costs a visible fraction of the year. One engineer on a migration for a quarter is five percent of the team's annual output. The same migration at eighty engineers is three tenths of one percent, which is why advice from large companies does not transfer.

At five engineers, the question is not "what is the best way to do this" but "what is the smallest number of systems that solves this, and can one of us debug each one at three in the morning." That usually produces one application, one primary datastore, one queue, and managed services for everything that is not the product.

4. Proportionality

Over-engineering is usually discussed as a technical mistake. It is a judgment mistake, and the distinction matters because the fix is different. A technical mistake is corrected with knowledge. A judgment mistake is corrected by comparing the design against the problem's actual size, out loud.

Two checks make it visible, and both take seconds.

• What is the smallest design that meets the stated requirements? Start there and add only what a requirement forces. Anything that survives has a reason attached.
• What would have to be true for this component to be necessary? If the answer is a scale or a failure mode you have not established, you have found something to remove, or at least something to defer with a trigger.

The second question also gives you an honest way to raise something you know is premature. "I would not build this now. I would build it when writes pass this number, which at current growth is about a year away." That is a stronger answer than either building it or omitting it silently. It shows you know the technique and know when it applies.

5. Build or Buy, Decided Honestly

All five constraints point at one recurring choice, which is whether to build a thing or use something that already exists. The honest comparison is not feature against feature. It is:

• The engineer-time to build it, plus the engineer-time to operate it forever, against the price.
• Whether it is part of what the product is for. A thing your customers notice and your competitors cannot copy is worth owning. Everything else is overhead, however enjoyable it is to build.
• Whether you could replace it later. A bought component behind a narrow interface is reversible. A bought component whose assumptions have spread through your codebase is not. That is a decision you make when you adopt it, not afterwards.

The short version is that you should build the thing that is the reason the company exists, and buy or borrow nearly everything else. That sounds obvious and is routinely violated, usually because building is more interesting than integrating.

6. The Senior Decision

A proportionate design is defended differently from an impressive one. It needs three sentences that an idealized design never has to supply.

1. The constraint that shaped it. "This team is five engineers with an existing on-call rotation, so I am keeping the number of systems to three."
2. What you deliberately did not build, and the trigger that would change it. "No separate search service. I would add one when the corpus passes a scale where the database's own search stops meeting latency targets."
3. What this costs you. "This design will need revisiting at roughly ten times current traffic, and I would rather pay that later than carry the complexity now."

Without them a simple design looks exactly like an inexperienced one, which is the specific risk of designing proportionately in an interview.

Complexity is not free, it is not neutral, and it is not primarily paid at build time. It is paid every week afterwards by whoever is on call, and in a small team those are the same people who are supposed to be building the product.

What the interviewer is scoring: the question that raises this is usually "would you use microservices here?", and it is a filter. The expected senior answer is no, with a migration path and the trigger that would change the answer. What is being assessed is whether you can reject a technique you clearly know, which reads as experience rather than ignorance, provided you attach the condition. A simple design presented without its constraints is the one case where this scores badly, because the interviewer cannot tell whether you chose it or defaulted to it. Say which constraint produced it, and the same design becomes a strong answer.