1.8 KiB
1.8 KiB
Architecture and System Design
Purpose
Shape meaningful technical direction so systems stay understandable, evolvable, and aligned with product needs over time.
When to use
- Designing a major feature or subsystem
- Changing service boundaries, module boundaries, or core data flow
- Evaluating multiple implementation approaches with long-term consequences
- Preparing work that will influence maintainability, scale, or team velocity
Inputs to gather
- Current architecture, boundaries, and pain points
- Product goals, scale expectations, and reliability constraints
- Existing patterns, platform constraints, and team operating model
- Compatibility, migration, and rollout concerns
How to work
- Start from the user or system outcome, then identify the simplest architecture that supports it well.
- Make tradeoffs explicit: complexity, performance, reliability, maintainability, and delivery speed.
- Preserve useful existing boundaries unless there is a clear reason to change them.
- Prefer designs that are easy to operate and easy for the team to understand.
- Document why the chosen path is better than the main alternatives.
Output expectations
- Clear recommended design or architecture direction
- Explicit tradeoffs and constraints
- Interfaces, boundaries, and rollout considerations that matter for implementation
Quality checklist
- The design solves the actual problem, not a hypothetical future one.
- Tradeoffs are named clearly enough to guide later decisions.
- Complexity is justified by concrete needs.
- Operational and migration consequences are not ignored.
Handoff notes
- Pair with architecture decision records when the choice should be preserved for future contributors.
- Call out which parts are decided versus intentionally deferred.