| name | systems-design |
| description | Design a multi-service or distributed system around responsibilities, protocols, topology, identity, consistency, failure, capacity, observability, and evolution. |
Systems Design
Use for architectures that span services, machines, networks, queues, distributed state, or operational domains.
Procedure
- Define system outcomes, environment, actors, scale, latency, availability, durability, and security constraints.
- Partition responsibilities and state ownership before selecting technologies.
- Define protocols, addressing/discovery, identity, authorization, message/data contracts, and versioning.
- Choose consistency and coordination semantics explicitly; identify what happens during partition, retry, duplicate delivery, and partial failure.
- Model capacity, backpressure, resource limits, queues, overload behavior, and recovery.
- Design observability around boundaries and end-to-end flows.
- Define deployment/evolution strategy so nodes or services can change without requiring impossible lockstep upgrades where practical.
- Test the hardest failure and scaling assumptions with prototypes or evidence.
Quality gate
The design should explain how the system behaves when parts fail, not only when every component is healthy.
