Ask a platform engineer why they chose one queue over another and you will get a technical answer. Throughput. Ordering guarantees. Operational maturity. These are real properties and they matter. But if you press further — if you ask why they chose those properties as the deciding ones — the answer usually stops being technical. It becomes something like: "I've seen the other one break in ways I don't want to debug at 3 AM." That is not a benchmark. That is taste.
Infrastructure work pretends to be a rigorous, quantitative discipline, and in the small it often is. In the large, it is almost entirely a taste problem. The interesting decisions — which abstractions to expose, which failure modes to accept, which operational overhead to inherit — do not have a single correct answer. They have a coherent answer, and coherence is an aesthetic property.
The myth of the objective tradeoff
The industry has trained us to talk about infrastructure in the language of tradeoffs. Latency vs throughput. Consistency vs availability. Cost vs performance. These framings are useful the same way a compass is useful: they tell you which direction you are heading, not where you should go.
The direction you should go is a function of what kind of system you want to be responsible for in three years. That is not a tradeoff question. That is a question about the shape of your life as an operator, and about what kinds of problems you find interesting to solve versus tedious to survive.
An engineer who loves distributed systems will happily accept the operational cost of a Kafka cluster because debugging partition rebalances is, to them, an intellectually rewarding activity. An engineer who finds that same activity soul-crushing will pick SQS and never regret it, even at a higher unit cost. Both are correct. The difference is taste.
Coherence over correctness
The best infrastructure I have worked with was not the most technically sophisticated. It was the most internally consistent. Every component made assumptions that the other components respected. The naming conventions were boring but predictable. The failure modes were all in the same shape, so the runbooks rhymed with each other.
Coherent infrastructure is easier to operate because your brain does not have to context-switch between mental models. You learn one set of primitives and they compose. You learn one debugging vocabulary and it transfers.
Incoherent infrastructure — the kind that accumulates when every team picks the "objectively best" tool for their slice — is exhausting in a way that no individual decision explains. Each choice was defensible. The whole is a swamp.
What good taste looks like in a platform
Good taste in infrastructure, in my experience, has a few tells.
The first is a willingness to say no to features that would fit but wouldn't belong. A platform with taste has a shape, and the shape is enforced even when a legitimate use case asks for something outside it. The use case gets solved somewhere else, or it doesn't get solved. The platform stays coherent.
The second is a suspicion of cleverness. Clever infrastructure is fun to build and awful to inherit. The engineer with taste writes the boring version, then writes it again, then deletes half of it. They ship something that looks obvious in retrospect, which is the highest compliment infrastructure can earn.
The third is a respect for the operator, who is usually a future version of themselves. Every knob is a promise. Every configuration option is a support ticket you have not yet received. Taste, in this context, is knowing which knobs are worth the promise.
Why this is hard to hire for
Taste does not show up on a resume. It shows up in the small choices an engineer makes when nobody is watching — the variable names, the error messages, the willingness to delete a file. You can only see it by working alongside someone, which is why the best platform teams tend to grow slowly and from within.
We think about this a lot at Fewzon. The product we are building is, at its core, a bet that a small team with unusually consistent taste can produce infrastructure that a much larger team could not. Whether that bet pays off is an empirical question. But the way we are working — heads-down, in a small room, with a lot of arguing about naming — is the version of the bet we know how to make.