Software Architecture Roadmap

Data structures and algorithms: hash tables, queues, graphs, trees — the ideas that reappear later as consistent hashing, message queues, dependency graphs and indexes. Taught in the DSA domain; come here first so those mechanisms feel familiar when they show up at system scale.

Before moving on: Say what a hash table, a queue, a tree and a graph cost per operation, and recognise each one when it reappears as a piece of infrastructure.

What to know before the rest makes sense: TCP connections and their cost, HTTP/1.1 vs HTTP/2 multiplexing, TLS termination, DNS and TTLs, status codes, the headers that control caching (Cache-Control, ETag), timeouts at every hop, and why a timeout is indistinguishable from a partition. Taught in the Networking domain.

Before moving on: Explain what a TCP connection and a TLS handshake cost, read Cache-Control and ETag headers, and say why a timeout looks the same as a network partition.

REST, GraphQL, gRPC, WebSockets, SSE and webhooks: what each solves, how each fails, and which to expose to whom. The first stage with lessons of its own — an API is the boundary every later component sits behind, so learn the boundary before the components.

Before moving on: Pick REST, GraphQL, gRPC, WebSockets, SSE or webhooks for a given consumer and say how each one fails on the wire and under load.

• API Architecture: REST, GraphQL, RPC, gRPC, WebSockets, WebhooksNot startedLearningPracticingMastered

What architecture is, how a system evolves one problem at a time, monolith and modular monolith, and the code-level structures — layered, clean, hexagonal — that keep dependencies pointing the right way. This is the single-process baseline; every stage after this one adds a component to it and pays for it.

Before moving on: Draw the components and dependency direction of a system, defend a monolith or modular monolith for a small team, and place a new feature in the right layer.

• What Is Software Architecture?Not startedLearningPracticingMastered
• From a Simple App to a Scaled SystemNot startedLearningPracticingMastered
• Monolithic ArchitectureNot startedLearningPracticingMastered
• Modular MonolithNot startedLearningPracticingMastered
• Layered ArchitectureNot startedLearningPracticingMastered
• MVC, MVP and MVVMNot startedLearningPracticingMastered
• Clean ArchitectureNot startedLearningPracticingMastered
• Hexagonal Architecture (Ports & Adapters)Not startedLearningPracticingMastered

Indexes, transactions, replication and partitioning: the database is the ceiling of most systems, and its behaviour drives the architecture around it. Taught in the Database Engineering domain; it comes right after the application because caching, scaling and distributed data are all reactions to what the database can and cannot do.

Before moving on: Choose an index for a query, explain what a transaction guarantees, and say what replication lag and a partition key do to the code around the database.

Browser → CDN → application cache → Redis → database: TTLs, invalidation, stampedes, hot keys, and what belongs at the edge. The first thing you add to protect the database, and it reuses the HTTP caching headers from the networking stage.

Before moving on: Place a cache at the right layer, choose a TTL and an invalidation strategy, and prevent a stampede on a hot key.

• Caching ArchitectureNot startedLearningPracticingMastered
• CDN ArchitectureNot startedLearningPracticingMastered

Point-to-point queues with acks, retries and dead letters, then Kafka-style logs with partitions, offsets and consumer groups. The queue from DSA becomes a component between two parts of the application, and it is the mechanism async processing and events are built on.

Before moving on: Design a producer and a consumer with acks, retries and a dead-letter queue, and explain what a Kafka partition and a consumer group guarantee about ordering.

• Message QueuesNot startedLearningPracticingMastered
• Kafka-Style Logs: Topics, Partitions, OffsetsNot startedLearningPracticingMastered

Background jobs and workers, idempotency under retries, and backpressure when producers outrun consumers. Once work goes through a queue it will be retried, so this stage is where "safe to run twice" becomes a design requirement.

Before moving on: Move slow work to a worker, make the job safe to run twice, and stop a backlog from taking the system down.

• Background Jobs and WorkersNot startedLearningPracticingMastered
• IdempotencyNot startedLearningPracticingMastered
• BackpressureNot startedLearningPracticingMastered

Vertical vs horizontal, why stateless services scale and stateful ones do not, and scaling a system step by step from one server to many. It needs the cache and the database stages first, because the walk-through adds those components in the order a real system does.

Before moving on: Take a system from one server to many one bottleneck at a time, and say which state has to leave the service before it can scale out.

• Horizontal vs Vertical ScalingNot startedLearningPracticingMastered
• Stateless vs Stateful ServicesNot startedLearningPracticingMastered
• Scale This SystemNot startedLearningPracticingMastered

Round robin, least connections and consistent hashing; health checks, sticky sessions, L4 vs L7, and the balancer as a single point of failure. Comes right after scaling: many stateless instances need something in front of them.

Before moving on: Choose an algorithm and a layer (L4 or L7) for a workload, configure health checks, and remove the balancer as a single point of failure.

• Load BalancingNot startedLearningPracticingMastered

Partitions and CAP without slogans, consistent hashing, service discovery in a dynamic fleet, and why one transaction cannot span services. Load balancing gave you a fleet; the database stage gave you transactions; this stage is what happens to both when the network is unreliable.

Before moving on: Explain what a partition forces you to give up, hash keys onto a fleet that changes size, find services without hard-coded addresses, and argue why a transaction cannot span two services.

• CAP and Distributed SystemsNot startedLearningPracticingMastered
• Consistent HashingNot startedLearningPracticingMastered
• Service DiscoveryNot startedLearningPracticingMastered
• Distributed TransactionsNot startedLearningPracticingMastered

Service boundaries, database ownership, partial failure and the API gateway — and the distributed monolith that results when the boundaries are not real. Deliberately late: it is the monolith from the application stage split along boundaries, with every distributed-systems cost attached.

Before moving on: Draw service boundaries that own their data, say what belongs in the gateway, and spot a distributed monolith from its deployment story.

• MicroservicesNot startedLearningPracticingMastered
• API GatewayNot startedLearningPracticingMastered

Event-driven architecture, the sync-vs-async decision, sagas with compensation, CQRS, and event sourcing — with duplicates, ordering and replay taken seriously. Built on the queue stage, and needed once services own separate databases and still have to agree.

Before moving on: Choose sync or async per interaction, write a saga with compensation, and handle duplicate, out-of-order and replayed events.

• Event-Driven ArchitectureNot startedLearningPracticingMastered
• Request/Response vs Event-DrivenNot startedLearningPracticingMastered
• Saga PatternNot startedLearningPracticingMastered
• CQRSNot startedLearningPracticingMastered
• Event SourcingNot startedLearningPracticingMastered

Timeouts, retries with budgets, circuit breakers, bulkheads, rate limiting, and the arithmetic of nines and error budgets. Every hop added since the application stage is a place to fail; this stage is the toolkit for failing on purpose instead of by accident, and it assumes the idempotency work from async processing.

Before moving on: Set timeouts and retry budgets per hop, wire a circuit breaker and a rate limiter, and turn an availability target into an error budget.

• Reliability PatternsNot startedLearningPracticingMastered
• Circuit BreakerNot startedLearningPracticingMastered
• Rate LimitingNot startedLearningPracticingMastered
• Availability, SLOs and Error BudgetsNot startedLearningPracticingMastered

Logs, metrics and traces for the same incident, and following one request across five hops to find where the time went. Only makes sense once there are hops to follow, so it comes after microservices.

Before moving on: Correlate a log line, a metric and a trace for one incident, and read a distributed trace to find the slow hop.

• Logs, Metrics and TracesNot startedLearningPracticingMastered
• Distributed TracingNot startedLearningPracticingMastered

Put it together: URL shortener, chat, social feed, e-commerce, notifications, file storage — requirements in, an evolving architecture out. The exercises use every stage above, so they come last.

Before moving on: Turn a requirements brief into an architecture with estimates, an API, a data model and its failure modes named, adding one component per problem.

Kill components and watch what breaks: the failure simulator turns every pattern above into an on-call decision. It closes the roadmap because reading its output takes the reliability and observability vocabulary.

Before moving on: Predict which user flows break when a component dies, and name the mitigation that keeps each flow degraded instead of failed.