The next engineer should be able to explain a request, diagnose a failure, and change the system with confidence.
Start with a request
An infrastructure design should be explainable through a single request. Where does it enter? What does it wait for? Which system owns the result? What happens if the caller gives up? Those questions turn an architecture diagram into something a team can operate.
Every new service should have a clear responsibility and a reason to exist separately. Otherwise, the team inherits another deployment, another dependency, and another place to investigate without necessarily giving the product a useful new capability.
Google’s SRE guidance treats simplicity as a property of the whole system, including interfaces and operations. That is a helpful standard for a growing project: evaluate a design by the work required to understand and change it, as well as the work it performs.
Make the first investigation obvious
When something breaks, the first few minutes should not depend on remembering a private collection of commands. A new engineer should be able to find the service owner, identify the affected requests, and see what changed.
Google’s monitoring guidance groups important service signals into latency, traffic, errors, and saturation. It also warns that monitoring can become difficult to maintain when the rules and dashboards grow too complex. A focused overview should lead toward a useful next question.
Design that overview alongside the service. Agree on what a successful request means, which failures need immediate attention, and which measurements distinguish a busy system from an unhealthy one. A dashboard earns its space when it supports a decision.
Leave room to change your mind
Early infrastructure choices are made with incomplete information. Keep the assumptions visible: expected demand, acceptable delay, data ownership, and the cost of an interruption. Write down what evidence would justify a more complex design.
That small record helps a team evolve deliberately. When demand changes, the discussion can start with a measured constraint instead of a vague sense that the architecture feels too small. It also makes it easier to remove components whose original purpose no longer applies.
Before calling a system ready, ask another engineer to explain a request and walk through a failure. The places where that explanation stalls are useful design feedback. Infrastructure becomes easier to improve when understanding it is ordinary team work.
David RhodusCEO, Permissionless Labs · Founder, Pipe Network