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.

Safety

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

Liveness

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

Observability

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

Controllability

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

Composability

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

Scalability

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

Related

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).