Software Architecture
System Design Thinking for Developers
A lightweight way to reason about trade-offs before writing production code.
In this article
Define Constraints First
Good system design starts with constraints, not components.
Clarify latency targets, expected load, consistency needs, and failure tolerance before choosing technologies.
Constraints are design inputs. Architecture is the output.
- Traffic profile (RPS, peaks, burst behavior)
- Latency budget (p50, p95, p99)
- Consistency requirements (strong vs eventual)
- Recovery expectations (RTO, RPO)
Constraint-first template
Document traffic profile, response budgets, and data correctness requirements.
This template prevents over-engineering and improves cross-team alignment.
1## Service Design Checklist\n- Goal: What user problem does this solve?\n- Latency: p95 < 250ms under expected peak\n- Resilience: Retry strategy and circuit breaker defined\n- Data: Idempotency and consistency model documented\n- Observability: SLI + alert thresholds availableDesign in Three Lanes
Break designs into data flow, failure flow, and growth flow.
If one lane is weak, the architecture will fail in production.
Failure flow planning
Model retries, fallbacks, and graceful degradation explicitly.
Resilience is a feature, not an afterthought.
Growth flow planning
Define scale thresholds and trigger points for upgrades.
This avoids panic migrations when usage spikes unexpectedly.
