Skip to content

Career roadmaps

Software Architect roadmap

Software architects make the big technical decisions: how systems are structured, which technologies to use, and how to balance speed, cost, reliability and security. It's usually a senior role reached after years of development. This roadmap shows the skills to build on the way.

Time
⏱ 6–12 months (for experienced developers)
Level
Advanced
Steps
6 steps
Architecture ↓Cheat sheet ↓5 interview Q&As ↓
Share

The roadmap

Click a step to open the full guide.

Best architecture: a modern SaaS platform (modular monolith first)

A pragmatic default for most companies: one deployable application with strong internal module boundaries, ready to split into services when there's a real need.

Modular monolith + platform

  1. Web & mobile clients · CDN
  2. API gateway (auth, rate limits)
  3. Application: Orders | Billing | Catalog | Users modules
  4. Event bus / outbox for async work
  5. PostgreSQL (schema per module) · Cache · Object storage
  6. Observability · CI/CD · IaC

Why it's built this way

  • Modules follow business domains (bounded contexts), not technical layers.
  • Modules talk through clear interfaces or events, never each other's tables.
  • One deployment keeps operations simple while the team is small.
  • An outbox + event bus makes async work reliable and eases a later split.
  • Extract a module into a service only when scaling, team autonomy or release speed demands it.

Software Architect cheat sheet

The essentials on one screen. Bookmark it for revision.

Style → best fit

Modular monolithSmall/medium teams, evolving domain
MicroservicesMany teams, independent scaling/deploys
Event-drivenDecoupled workflows, integrations
ServerlessSpiky, event-based, low ops
CQRSVery different read and write models

Architect's toolkit

C4 modelDiagrams at 4 zoom levels
ADRRecord decisions and why
Event stormingDiscover domains with experts
Fitness functionsAutomated architecture checks
Well-Architected reviewsCloud best-practice checklist

Improve performance

  • Design for the expected load with headroom, and measure early.
  • Keep hot paths in-process; avoid chatty network calls between services.
  • Cache and precompute for read-heavy features.
  • Use async/event-driven flows for slow or non-critical work.
  • Define performance budgets and enforce them with fitness functions.

Security checklist

  • Security by design: threat-model new systems and major changes.
  • Zero-trust between services; least-privilege everywhere.
  • Centralised identity, secrets management and audit logging.
  • Data classification and encryption policies.
  • Compliance requirements (e.g. data residency) as first-class constraints.

Most important interview questions

Click a question to see a strong answer. Each step also has its own questions.

1What does a software architect do?

Defines system structure and technology choices, balances quality attributes against business goals, documents decisions, guides teams and manages technical risk.

2How do you migrate a monolith to microservices?

Strangler fig pattern: put a facade in front, extract one bounded context at a time with its own data, route traffic gradually, and keep both running until the old path can be removed.

3How do you ensure consistency across microservices?

Avoid distributed transactions; use sagas (orchestrated or choreographed) with compensating actions, the outbox pattern for reliable events, and idempotent consumers.

4What is the strangler fig pattern?

Incrementally replacing parts of a legacy system by routing specific functionality to new components until the old system can be retired.

5How do you evaluate a new technology?

Define the problem and criteria, prototype against real requirements, assess maturity, support, cost, skills and exit strategy, then record the decision in an ADR.

Related roadmaps

6

System Design

6 steps · 8–10 weeks · Advanced

Design scalable, reliable systems and ace design interviews.

View roadmap →
6

Cloud Engineer

6 steps · 5–7 months · Intermediate

Design, build and run systems on AWS, Azure or Google Cloud.

View roadmap →
6

Backend Developer

6 steps · 5–6 months · Intermediate

Build the APIs, databases and services behind apps.

View roadmap →
6

AI Engineer

6 steps · 4–6 months · Intermediate

Build products on top of large language models.

View roadmap →
1

Software Architect · Step 1 of 6 · 3 weeks

Architecture styles

Monoliths, microservices, events and serverless.

There's no best style, only the best fit. A modular monolith is often right for small teams; microservices help when many teams need to deploy independently; event-driven designs decouple services; serverless suits spiky, event-based workloads.

What you'll learn

  • Layered and modular monoliths
  • Microservices
  • Event-driven architecture
  • Serverless
  • Hexagonal / clean architecture
  • When to use each

Monolith vs microservices

Modular monolith

  • Simple to deploy & debug
  • In-process calls
  • Best for small/medium teams

Microservices

  • Independent deploys & scaling
  • Network calls, eventual consistency
  • Best for many teams

Key concepts

Modular monolith
One deployable app with strong internal boundaries.
Microservices
Independently deployable services owned by separate teams.
Coupling
How much one part depends on another. Lower is easier to change.

Step by step

  1. 1.1

    Know the styles

    Layered, modular monolith, microservices, event-driven, serverless.

  2. 1.2

    Know the costs

    Network calls, data consistency, deployment and monitoring overhead.

  3. 1.3

    Match to context

    Team size, domain complexity, scale, budget.

Notes

  • Microservices trade code complexity for operational complexity.
  • Most systems should start as a well-structured monolith.

Tips & tricks

  • For each style, list three situations where it's the wrong choice.

Interview questions

When would you choose microservices?

When many teams need to deploy independently, parts have very different scaling needs, and you have the platform maturity (CI/CD, observability) to run them.

The quick way to study this

Compare four styles on team size, scaling, complexity and cost.

2

Software Architect · Step 2 of 6 · 2 weeks

Quality attributes and trade-offs

Design for what really matters to the business.

Architecture is the art of trade-offs between quality attributes. Make them explicit: a banking ledger prioritises consistency and security; a social feed prioritises availability and speed.

What you'll learn

  • Scalability
  • Availability and reliability
  • Performance
  • Security
  • Maintainability
  • Cost

Quality attributes

Architecture decision
  • Performance
  • Availability
  • Security
  • Cost
  • Maintainability
  • Scalability

Key concepts

Quality attribute
A non-functional goal like availability or latency.
Fitness function
An automated check that the architecture keeps a quality (e.g. p95 < 300 ms).

Step by step

  1. 2.1

    Identify attributes

    Performance, availability, security, cost, maintainability.

  2. 2.2

    Prioritise

    Agree the top three with stakeholders.

  3. 2.3

    Make trade-offs explicit

    Document what you gave up and why.

Notes

  • You can't maximise everything; name what you're trading.

Tips & tricks

  • Rank the top three quality attributes with stakeholders before designing.

Interview questions

How do you resolve conflicting quality requirements?

Make the conflict explicit, tie each attribute to business impact, agree priorities with stakeholders, and record the decision in an ADR.

The quick way to study this

Pick three real apps and rank their top quality attributes.

3

Software Architect · Step 3 of 6 · 3 weeks

Domain-driven design and APIs

Structure systems around the business.

Domain-driven design splits a system along business boundaries (bounded contexts), each with its own model and language. These boundaries are natural service or module boundaries and reduce coupling between teams.

What you'll learn

  • Bounded contexts
  • Ubiquitous language
  • Aggregates
  • API design and versioning
  • Contracts between teams

E-commerce bounded contexts

Context map
  • Catalog
  • Orders
  • Payments
  • Shipping
  • Customers
  • Notifications

Key concepts

Bounded context
A part of the business with its own model and language.
Aggregate
A cluster of objects changed together as one unit.
Anti-corruption layer
Translator protecting your model from another system's model.

Step by step

  1. 3.1

    Discover domains

    Event storming with domain experts.

  2. 3.2

    Draw context map

    Bounded contexts and how they relate.

  3. 3.3

    Define contracts

    APIs and events between contexts, versioned.

Notes

  • Service boundaries should follow business boundaries, not technical layers.

Tips & tricks

  • Run an event-storming session to discover domains.

Interview questions

How do you decide service boundaries?

Follow business capabilities and bounded contexts, minimise chatty cross-boundary calls, and align boundaries with team ownership.

The quick way to study this

Map the bounded contexts of an e-commerce system.

4

Software Architect · Step 4 of 6 · 3 weeks

Cloud, data and AI architecture

Modern platforms and where AI fits.

Architects now design for the cloud by default and increasingly add AI: model gateways, RAG pipelines, evaluation and guardrails. Cost is an architectural concern too.

What you'll learn

  • Cloud reference architectures
  • Data platforms and pipelines
  • Caching and CDNs
  • AI/LLM architecture (RAG, agents, gateways)
  • Cost architecture

Adding AI to a platform

  1. Product features
  2. AI orchestration (prompts, tools, agents)
  3. AI gateway (routing, quotas, logs)
  4. Model providers · Vector DB · Feature store
  5. Evals, guardrails, cost dashboards

Key concepts

AI gateway
A layer in front of model APIs for routing, limits, logging and cost.
CQRS
Separate models for writes and reads, when they differ a lot.

Step by step

  1. 4.1

    Cloud reference designs

    Multi-AZ, managed services, IaC.

  2. 4.2

    Data architecture

    Operational DBs, events, analytics warehouse.

  3. 4.3

    AI architecture

    Model gateway, RAG, evals, guardrails, cost controls.

Notes

  • Put an AI gateway in front of model providers for routing, limits and logging.

Tips & tricks

  • Read your cloud provider's well-architected guidance.

Interview questions

How would you add LLM features to an existing product safely?

Start with a narrow use case, route model calls through a gateway, ground answers with RAG, add evals and guardrails, keep humans in the loop for risky actions, and monitor cost and quality.

The quick way to study this

Draw a reference architecture for an AI-powered SaaS app.

AI Engineer roadmap →
5

Software Architect · Step 5 of 6 · 2 weeks

Documentation and decision-making

Communicate designs so teams can build them.

Architects work through documents and conversations. The C4 model draws systems at four zoom levels; ADRs record what was decided and why, so future teams understand the reasoning.

What you'll learn

  • C4 model diagrams
  • Architecture decision records (ADRs)
  • Design reviews
  • RFCs
  • Technical roadmaps

C4 zoom levels

  1. 1. System context (users & external systems)
  2. 2. Containers (apps, DBs, queues)
  3. 3. Components (inside a container)
  4. 4. Code (classes, optional)

Key concepts

C4 model
Four zoom levels of architecture diagrams.
ADR
Architecture decision record: a short note of a decision and why.

Step by step

  1. 5.1

    C4 diagrams

    Context → containers → components → code.

  2. 5.2

    ADRs

    Context, decision, alternatives, consequences.

  3. 5.3

    Design reviews

    Share early, invite challenge, decide and record.

Notes

  • An ADR is short: context, decision, consequences.

Tips & tricks

  • Write an ADR for every significant decision, including rejected options.

Interview questions

What goes into an architecture decision record?

Title, status, context (the problem and forces), the decision, alternatives considered, and consequences (positive and negative).

The quick way to study this

Write three ADRs and a C4 context diagram for a project you know.

6

Software Architect · Step 6 of 6 · Ongoing

Leadership and governance

Influence without authority.

Architects succeed through influence: explaining trade-offs to executives, mentoring developers and guiding teams to consistent decisions. Manage technical debt deliberately and keep security and compliance in view.

What you'll learn

  • Leading design reviews
  • Mentoring
  • Technical debt management
  • Security and compliance
  • Stakeholder communication

Architecture governance loop

  1. Principles
  2. Team decisions (ADRs)
  3. Reviews
  4. Measure (fitness functions)
  5. Improve

Repeats as a loop

Key concepts

Technical debt
Shortcuts that make future change slower unless repaid.
Architecture principles
Shared rules that guide teams' decisions.

Step by step

  1. 6.1

    Run reviews

    Facilitate, don't dictate; focus on risks.

  2. 6.2

    Manage debt

    Track it, quantify impact, schedule paydown.

  3. 6.3

    Grow others

    Mentor, share principles, document patterns.

Notes

  • Good architects make themselves less necessary by spreading good judgement.

Tips & tricks

  • Translate technical risks into business impact (cost, risk, time).

Interview questions

How do you convince leadership to invest in technical debt?

Quantify impact in business terms (slower releases, incidents, cost), propose a focused plan with measurable outcomes, and tie it to upcoming business goals.

The quick way to study this

Lead one design review and ask for feedback on how you ran it.

Share this page