Principles of Good Systems ⬢

Principles of Good Systems ⬢

These are qualities of a good system that we should strive to fulfill with what we design. Without fulfilling each of these attributes, the system is much more likely to fail in its goal.

This details here are a work-in-progress. Make a pull-request if you have suggested changes.


Nothing bad can happen. Access Control Logic, Resource Limits, interlocks, jigs/poka-yoke


Something good happens, eventually. Desired State interfaces, Slack capacity, (more about safety and liveness)


Activity, configuration, and behavior within the system is legible and actionable by users (and admins/developers). Data used to scale the system is a first-class entity, logs-as-data


Users (and admins/developers) can cleanly and clearly direct the system to operate within their desired bounds. Feedback mechanisms, tenacy-based limits, progressive disclosure of manual overrides


Complex behavior can be created with the system by assembling components. Pieces can be swapped, edited, etc. in isolation (without considering the full state of the system). There is only one source of truth for data and control in the system. Desired state and declarative interfaces, Narrow waist protocols, Domain Driven Design


More work can be done by the system by adding resources. The system does not impede its own expansion. The cost of adding incremental work is approximately constant. Caching layers, horizontal load balancing

Often, people will say that they want to optimize a system for “reliability.” In my experience, this term really is a combination of both safety and liveness. What’s reliable? A system that does what I want (liveness) and doesn’t do the things I don’t want (safety). Untitled-2023-05-18-1052