SYSTEM ATLAS

How a request
becomes a response.

Every deployed system is a chain of small, specialized parts passing traffic to each other. This is a map of that chain — the patterns, the traffic controllers, the containers, and the cloud pieces that hold it together.

// request path, left to right
Client
browser / app
CDN / Edge
DNS + cache
Load Balancer
traffic split
App tier · 3 replicas
Cache
redis / memcached
Database
primary + replica
Client — sends the request Edge — nearest copy, fastest reply Load Balancer — decides which server Cache — skips the slow path Database — the source of truth
Deep dive

Every hop, in order

The hop-by-hop version. Nothing skipped: security checks, routing, business logic, and the async work that happens after the response has already gone back.

// full request journey, left to right
Client
browser / app
DNS
name → IP
CDN / Edge
nearest cache
WAF
blocks bad traffic
Load Balancer
traffic split
API Gateway
routes + rate-limits
Auth Service
checks token
App tier · microservices
Cache
checked first
Message Queue
async jobs
Database
primary + replica
Observability (logs, metrics, traces) watches every hop above — this is how you see a slowdown before a user reports it.
The response travels back through the same chain in reverse. Anything written to the Message Queue keeps processing after the client already has its reply — that's what makes it "async."
Structures

Three ways to shape an app

The same features can be shipped as one deployable unit, as many independent services, or as functions that only exist while they run. Each shape trades simplicity for flexibility differently.

Monolith

UI · Business Logic · Data Accessone codebase, one deploy
Best for small teamsfast MVPs
  • Simple to develop, test, and deploy
  • One codebase, easy to reason about
  • Lower operational overhead
Scaling means scaling the whole thing, not just the busy part.

Microservices

API Gateway
Auth
Orders
Payments
Users
Best for large teamsindependent scaling
  • Each service scales and deploys on its own
  • Teams can own a service end-to-end
  • A failure can stay contained
More moving parts means more to monitor and coordinate.

Serverless

API Gateway
fn: resize()
fn: notify()
fn: charge()
Best for spiky trafficevent-driven work
  • No servers to patch or provision
  • Pay only for the time code actually runs
  • Scales to zero and back automatically
Cold starts and vendor-specific limits need planning around.
Traffic

Deciding which server gets the request

A load balancer sits in front of every replica and picks one for each incoming request. The algorithm it uses changes how evenly, and how intelligently, traffic gets spread.

Round Robin

Cycles through servers in fixed order, one request after another.

NGINXHAProxy

Least Connections

Sends the request to whichever server currently has the fewest open connections.

AWS ALBHAProxy

Weighted

Gives bigger servers a larger share of traffic based on assigned capacity weights.

NGINXGCP LB

IP Hash

Routes the same client to the same server every time, based on their IP.

NGINXAWS NLB

Geo-based

Routes each request to the data center or edge location physically closest to it.

CloudflareRoute 53

Health-checked failover

Skips any server failing its health check until it reports healthy again.

AWS ALBGCP LB
Packaging

Docker builds it. Kubernetes runs it.

Docker packages an app and everything it needs into one portable image. Kubernetes takes that image and keeps many copies of it alive, healthy, and reachable across a cluster of machines.

Docker image layers
CMD ["start"]L4
COPY . .L3
RUN install depsL2
FROM base imageL1
Kubernetes cluster
CONTROL PLANE — decides what should run where
API Server Scheduler etcd Controller Mgr
WORKER NODES — actually run the pods
node-1 · kubelet
node-2 · kubelet
node-3 · kubelet
Infrastructure

Same job, different cloud, different name

Every provider offers a version of the same building blocks. Knowing the job each block does matters more than memorizing any one vendor's name for it.

Compute
AWSEC2
GCPCompute Engine
AzureVirtual Machines
Storage
AWSS3
GCPCloud Storage
AzureBlob Storage
Database
AWSRDS
GCPCloud SQL
AzureAzure SQL
CDN / Edge
AWSCloudFront
GCPCloud CDN
AzureAzure CDN
DNS
AWSRoute 53
GCPCloud DNS
AzureAzure DNS
Messaging / Queue
AWSSQS / SNS
GCPPub/Sub
AzureService Bus
Monitoring
AWSCloudWatch
GCPCloud Monitoring
AzureAzure Monitor
CI / CD
AWSCodePipeline
GCPCloud Build
AzureAzure DevOps
Secrets / Identity
AWSIAM + KMS
GCPIAM + Secret Mgr
AzureAD + Key Vault
Rest of the kit

The pieces that keep it reliable

Beyond the core path, these are the parts that make a system resilient, observable, and safe to change.

Scaling & Routing
Auto-scaling groups (ASG) Horizontal Pod Autoscaler API Gateway Reverse proxy (NGINX / Traefik) Service Mesh (Istio / Linkerd)
Caching & Data
In-memory cache (Redis / Memcached) Edge / CDN caching Read replicas Connection pooling
Messaging & Events
Kafka RabbitMQ Event-driven pub/sub Webhooks
Observability
Logs (ELK / Loki) Metrics (Prometheus + Grafana) Tracing (Jaeger / OpenTelemetry) Uptime alerting
Security
TLS / SSL termination WAF Secrets manager Rate limiting
Deployment strategies
Blue-Green deploys Canary releases Rolling updates CI/CD pipeline