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