Software Architecture

How should I structure a software system, and why? Not a tour of buzzwords: every architecture here is explained by the problem that caused it, the moment it stops paying for itself, and the way it fails in production.

The judgment we teach

Architecture is a sequence of decisions under measured constraints. The skill is knowing which problem you actually have.

  1. Learn→
  2. Visualize→
  3. Compare→
  4. Design→
  5. Simulate→
  6. Debug→
  7. Practice→
  8. Interview
Every topic answers eight questions
  1. What problem does it solve?
  2. When should I use it?
  3. When should I avoid it?
  4. What are the tradeoffs?
  5. How does it fail?
  6. How does it scale?
  7. How does data move through it?
  8. How does it talk to databases, queues, caches, APIs and external systems?
The rules that matter most
A monolith is not automatically bad architecture. Microservices must solve a real organisational or scaling problem. Every rung of the scaling ladder buys capacity by adding a problem. Retries can make an outage worse. “Exactly-once” is at-least-once plus idempotency. The simplest architecture that meets a measured requirement wins.

Start here

Learn
36 lessons across 11 modules. Every lesson answers the same eight questions and carries an interactive.
Architecture Finder
“What architecture should I use?” — team size, deployment independence, data ownership, reliability, complexity tolerance → recommendation, why, risks, alternatives.
Failure Simulator
Kill the cache, the database, the queue or the payment provider and see which user flows break, degrade, retry, or lose data.
Diagram Builder
Place clients, gateways, services, databases, queues, caches and workers; connect them; get single points of failure, bottlenecks and coupling called out.
Practice
14 production incidents to investigate and 6 system design exercises built one problem at a time.
Interview
46 questions with beginner / strong / expert answers, green & red flags and follow-ups.
Tradeoff Explorer
Monolith vs microservices, REST vs gRPC, sync vs async, CQRS vs CRUD — use when, avoid when, complexity, ops cost, failure modes.
Cross-Domain Map
How hash tables become consistent hashing, queues become message queues, transactions become sagas, and tool calling becomes integration.

Modules

0/36 lessons mastered
Architecture Fundamentals0/2
What architecture is — components, boundaries, dependencies, data flow, failure domains — and how a system evolves from browser → backend → database.
Application Architecture0/3
Monolith, modular monolith, microservices: what each solves, what each costs, and the decision between them.
Code Architecture0/3
Layered, Clean and Hexagonal: dependency direction, domain isolation, and when the abstraction stops paying for itself.
Events & Messaging0/4
Event-driven architecture, queues, Kafka-style logs, and the sync-vs-async decision — with duplicates, ordering and replay taken seriously.
APIs & Gateways0/2
REST, GraphQL, RPC/gRPC, WebSockets, webhooks — which to expose to whom — and what belongs in an API gateway.
Scaling & Caching0/6
Load balancing, stateless services, cache layers, CDNs, horizontal vs vertical — and scaling a system one real problem at a time.
Async Processing0/3
Background jobs, workers, idempotency under retries, and backpressure when producers outrun consumers.
Distributed Data0/4
Why one transaction cannot span services: sagas, compensation, CQRS and event sourcing — and why most apps need none of them.
Reliability0/4
Retry, backoff, timeouts, circuit breakers, bulkheads, rate limiting, graceful degradation, and the arithmetic of nines.
Distributed Systems0/3
Consistent hashing, service discovery, partitions and CAP without slogans.
Observability0/2
Logs, metrics and traces; following one request across services and finding where the time went.

From fundamentals to production

The defining feature of Engineer Atlas: how a computer-science concept becomes a real system. Each journey crosses domains.

Hash Tables → Database Hash Join → Consistent Hashing → Distributed Cache
One idea — hash a key to find where it lives — from an array of buckets to a ring of servers.
  1. DSAHash Tables→
  2. DatabaseHash Join→
  3. ArchitectureConsistent Hashing→
  4. ArchitectureDistributed Cache
Queues → Message Queues → Sync vs Async → Event-Driven Architecture
From FIFO in memory to a broker between processes to a system that announces facts instead of making calls.
  1. DSAQueues→
  2. ArchitectureMessage Queues→
  3. ArchitectureSync vs Async→
  4. ArchitectureEvent-Driven
Vector Search → Vector Storage → RAG → Agent + RAG
Similarity over embeddings becomes retrieval infrastructure, then the memory an agent reasons over.
  1. DatabaseVector Search→
  2. Agentic AIVector Storage→
  3. Agentic AIRAG→
  4. Agentic AIAgent + RAG
ACID → Distributed Consistency → Distributed Transactions → Sagas
What one database guarantees, what replication weakens, what services lose, and how a saga gets part of it back.
  1. DatabaseACID→
  2. DatabaseDistributed Consistency→
  3. ArchitectureDistributed Transactions→
  4. ArchitectureSagas
All journeys and cross-domain connections →

Connected to the other domains

The same mechanisms, seen from the system side.

DSA → Architecture
Hash tables become consistent hashing; queues become message queues; graphs become dependency graphs; token buckets become rate limiters.
Databases → Architecture
Replication becomes read scaling; transactions become sagas; sharding becomes horizontal scale; indexes become performance architecture.
Agentic → Architecture
Tool calling is external service integration; agents are workflow architecture; RAG is retrieval infrastructure; evals are AI reliability.