PrepZone Logo
PrepZone
Start Free Trial

System Design Building Blocks Map

The complete toolbox — DNS, LB, cache, DB, queue, CDN — and how they connect in every design.

AdvancedTheory14 min read

Read these first

StreamHub started as one server. Today it runs through GeoDNS, a CDN, API gateway, stateless services, Redis, Postgres with read replicas, Kafka, and S3. This article maps the toolbox and shows where each piece fits.

The complete toolbox

Cloud building blocks toolbox

NETWORKRoute 53DNS + GeoDNS
NETWORKCloudFrontCDN edge
NETWORKAWS ALBL7 balance
NETWORKAPI Gatewayauth + throttle
COMPUTEAmazon EKScontainer fleet
DATABASEElastiCacheRedis cache
DATABASERDS / Aurorarelational
DATABASEDynamoDBkey-value
INTEGRATIONMSK / SQSasync events
STORAGEAmazon S3object store
ANALYTICSOpenSearchfull-text
OPSCloudWatchmetrics · logs
SECURITYAWS WAFedge security
SECURITYCognitoidentity
COMPUTELambdaserverless
INTEGRATIONSNS / SESnotify
Every StreamHub product design combines subsets of these AWS components.
BlockPurposeStreamHub usage
DNS / GeoDNSResolve hostname; route to nearest regionstreamhub.com → US/EU/APAC clusters
CDNCache static and edge-cacheable content at PoPsVideo segments, thumbnails, JS bundles
Load balancerDistribute traffic across app serversALB across EKS pods
API gatewayAuth, rate limiting, routing, TLS terminationKong at edge; JWT validation
Cache (Redis)Sub-ms reads for hot dataStream metadata, sessions, rate limits
DatabaseDurable source of truthPostgres primary + read replicas
Message queueAsync decoupling and spike absorptionKafka events, RabbitMQ jobs
Object storeBlob storage for files and mediaS3 for VOD, clips, profile images
Search indexFull-text and autocomplete queriesElasticsearch for stream discovery

  • DNS / GeoDNS

    PurposeResolve hostname; route to nearest region
    StreamHub usagestreamhub.com → US/EU/APAC clusters

  • CDN

    PurposeCache static and edge-cacheable content at PoPs
    StreamHub usageVideo segments, thumbnails, JS bundles

  • Load balancer

    PurposeDistribute traffic across app servers
    StreamHub usageALB across EKS pods

  • API gateway

    PurposeAuth, rate limiting, routing, TLS termination
    StreamHub usageKong at edge; JWT validation

  • Cache (Redis)

    PurposeSub-ms reads for hot data
    StreamHub usageStream metadata, sessions, rate limits

  • Database

    PurposeDurable source of truth
    StreamHub usagePostgres primary + read replicas

  • Message queue

    PurposeAsync decoupling and spike absorption
    StreamHub usageKafka events, RabbitMQ jobs

  • Object store

    PurposeBlob storage for files and media
    StreamHub usageS3 for VOD, clips, profile images

  • Search index

    PurposeFull-text and autocomplete queries
    StreamHub usageElasticsearch for stream discovery

How blocks connect

StreamHub production architecture (AWS)

HTTPSstaticmissAPICLIENT
Mobile / WebStreamHub cli…NETWORK
Route 53GeoDNS routingNETWORK
CloudFrontCDN + WAF edgeNETWORK
AWS ALBTLS terminati…NETWORK
API GatewayJWT · rate li…STORAGE
Amazon S3media originCOMPUTE
Amazon EKSAPI · auth · …DATABASE
ElastiCachesessions · ho…DATABASE
RDS Postgresprimary + rep…INTEGRATION
Amazon MSKdomain eventsANALYTICS
OpenSearchstream discov…OPS
CloudWatchmetrics · X-R…
End-to-end path from user to data — reference this when placing any new service.

Typical request path

  • User resolves streamhub.com via DNS → GeoDNS routes to nearest region.
  • Static assets served from CDN edge; cache miss fetches from origin once.
  • API requests hit load balancer → gateway (auth + rate limit) → app service.
  • App reads Redis cache → Postgres on miss → publishes events to Kafka on writes.
  • Media uploads go directly to S3 via presigned URLs; transcode workers pull from queue.

Growth stages

Stage 1EC2 + Postgres on one box
Stage 2RDS + separate EC2 app
Stage 3ALB + ASG + ElastiCache Redis
Stage 4CloudFront + S3 media origin
Stage 5MSK Kafka + EKS worker fleet
Stage 6Sharded RDS + multi-region EKS
Each stage adds one AWS building block when the previous bottleneck appears.
AspectStage 1–2 (0–100K users)Stage 5–6 (10M+ users)
ComputeSingle server → LB + app fleetMulti-region K8s with HPA
DataSingle PostgresSharded DB + read replicas + Redis cluster
MediaLocal diskS3 + CDN + transcoding pipeline
AsyncNone → simple queueKafka + worker fleets + event-driven fan-out
OpsManual deploysObservability stack, SLOs, multi-region failover

  • Compute

    Stage 1–2 (0–100K users)Single server → LB + app fleet
    Stage 5–6 (10M+ users)Multi-region K8s with HPA

  • Data

    Stage 1–2 (0–100K users)Single Postgres
    Stage 5–6 (10M+ users)Sharded DB + read replicas + Redis cluster

  • Media

    Stage 1–2 (0–100K users)Local disk
    Stage 5–6 (10M+ users)S3 + CDN + transcoding pipeline

  • Async

    Stage 1–2 (0–100K users)None → simple queue
    Stage 5–6 (10M+ users)Kafka + worker fleets + event-driven fan-out

  • Ops

    Stage 1–2 (0–100K users)Manual deploys
    Stage 5–6 (10M+ users)Observability stack, SLOs, multi-region failover

Choosing blocks for a new feature

Decision prompts

  • Read-heavy? Add cache (Redis) and/or CDN before scaling DB replicas.
  • Write spikes? Add queue to decouple; never synchronous fan-out to N services.
  • Large files? Object store + CDN; never store blobs in Postgres.
  • Real-time? WebSocket service + Redis pub/sub for cross-pod message relay.
  • Search? Dedicated search index (Elasticsearch); don't query Postgres with LIKE.
  • Global users? Multi-region with GeoDNS; accept eventual consistency or CRDTs.

Cross-cutting concerns

ConcernBlock(s)Notes
AuthenticationAPI gateway + OAuth2/OIDCValidate JWT at edge; propagate user context
Rate limitingGateway middleware + RedisToken bucket per user tier
ObservabilityOpenTelemetry → metrics/logs/tracesInstrument every block, not just app code
IdempotencyRedis or DB key storeRequired wherever queues or retries exist
ConsistencyDB transactions + outbox + cache invalidationPick CP or AP per entity type

  • Authentication

    Block(s)API gateway + OAuth2/OIDC
    NotesValidate JWT at edge; propagate user context

  • Rate limiting

    Block(s)Gateway middleware + Redis
    NotesToken bucket per user tier

  • Observability

    Block(s)OpenTelemetry → metrics/logs/traces
    NotesInstrument every block, not just app code

  • Idempotency

    Block(s)Redis or DB key store
    NotesRequired wherever queues or retries exist

  • Consistency

    Block(s)DB transactions + outbox + cache invalidation
    NotesPick CP or AP per entity type

Quick recall

Everything you need if you only revisit this box.

  • Every product design combines subsets of DNS, CDN, LB, gateway, cache, DB, queue, object store.
  • Add blocks when a specific bottleneck appears — don't over-engineer stage 1.
  • Read path: DNS → CDN → LB → gateway → cache → DB.
  • Write path: API → DB + cache invalidation + queue for async side effects.
  • StreamHub journey: single server → LB → cache → CDN → queue → sharded DB → multi-region.
  • Cross-cutting: auth at gateway, rate limits in Redis, observability everywhere.

Test yourself

Answer these before moving on — recall is what makes it stick.