The architects are to convert a vague business need → technical system structure.
The process has 6 phases:
- Clarify the real problem
- Identify constraints
- Define system boundaries
- Design data flow
- Choose architecture patterns
- Evaluate tradeoffs & risks
1) Clarify the Real Problem (MOST important step)
Architects don’t start with databases or APIs.
They start with questions.
Because most initial requirements are wrong, incomplete, or actually describing a symptom.
Example request:
“We need real-time notifications.”
You must translate that into measurable properties.
You ask things like:
Users
- Who uses it?
- How many users?
- Are they humans or machines?
- Geographic distribution?
Behavior
- What triggers the action?
- How fast must it happen?
- What happens if it’s late?
Business importance
- Is this revenue-critical?
- Can it fail?
- How often?
This step is called: Requirement decomposition
Your output is not a design.
Your output is a problem statement:
“We need to deliver events to up to 50k concurrent users within 2 seconds, losing at most 0.1% messages, with 99.9% uptime.”
Now architecture becomes possible.
2) Identify Constraints (THIS actually shapes architecture)
The same system under different constraints produces completely different designs.
You must extract:
Technical constraints
- cloud? on-prem?
- existing stack? (for you: Rust matters a lot)
- latency requirements
- storage requirements
- security requirements
Organizational constraints
This is the part engineers underestimate:
- team size
- expertise
- maintenance ability
- deployment frequency
Example:
A 3-person startup → monolith often best
A 40-team company → services necessary
The best architecture is the one your team can operate.
3) Define System Boundaries
Now you draw your first box.
Architects do not start with classes or functions.
They start with:
“What is inside the system vs outside?”
You define:
- external actors (users, other services)
- dependencies
- ownership
This produces a context diagram.
You are deciding:
What is our responsibility and what is not?
This is extremely important — most system failures come from unclear boundaries.
4) Design the Data Flow (this is the real architecture)
Architecture is actually about movement of information.
Not frameworks.
Not languages.
Not microservices.
You now answer:
How does information enter, transform, persist, and leave the system?
You design a pipeline:
- Input
- Validation
- Processing
- Storage
- Output
You should literally be able to narrate:
“User action → API → queue → worker → database → notification → client”
At this stage:
No specific technology yet.
Only logical components.
5) Choose Architecture Patterns
Now (finally) you pick structure.
You are mapping the data flow onto known patterns.
Common options:
Monolith
Best when:
- small team
- fast iteration
- low scale
- evolving product
Layered Architecture
(API → Service → Repository → DB)
Good default for most systems.
Event-Driven
When:
- asynchronous processing
- decoupling required
- high throughput
Microservices
Only when:
- independent teams
- clear domain boundaries
- scaling bottlenecks
Important architect skill:
Knowing when not to use microservices.
90% of systems should not start as microservices.
6) Evaluate Tradeoffs (the real job)
This is actually the core of architecture.
There is no correct architecture.
There are only tradeoffs.
You must explicitly analyze:
| Property | Questions |
|---|---|
| Scalability | What happens at 10× load? |
| Reliability | What fails first? |
| Consistency | Can data be wrong? |
| Latency | Worst case response? |
| Operability | Who debugs at 3am? |
| Cost | Cloud bill growth? |
An architect’s output is not a diagram.
It is:
A justification document explaining why this design is better than alternatives.
What Architects Actually Produce
You might think they produce UML diagrams.
No.
They produce decisions.
Examples:
- Why not WebSockets?
- Why queue instead of direct calls?
- Why PostgreSQL not Redis?
- Why eventual consistency is acceptable?
Architecture is the art of:
making irreversible decisions carefully.
A Practical Mental Model (memorize this)
Whenever given a system problem, run this sequence:
- What problem are we really solving?
- What constraints dominate the design?
- What are the system boundaries?
- How does data move?
- Which architecture pattern fits that flow?
- What are the tradeoffs and failure modes?
Concerns:
memory correctness
defensive programming
debugging ability
reasoning aloud
data structure choice
code clarity
Memory
- stack vs heap
- new/delete
- smart pointers (VERY IMPORTANT)
- unique_ptr
- shared_ptr
- weak_ptr
STL you must know
Not everything. Just:
- vector
- string
- unordered_map
- map
- deque
- list
- pair
- iterators