SysPad › Examples

Cloud architecture examples

45 cloud architecture examples you can open, simulate and edit in the browser: reference designs, production-scale systems, and interview practice problems.

Reference architectures

Recognisable systems modelled end to end, sized and ready to simulate.

• 3-tier web app: A modern web stack: edge network, load balancer, API on Kubernetes, cache, database, and a payments API.
• Photo sharing app: Instagram-style feed: media CDN, autoscaled API, Redis feed cache, social-graph DB, search, and async image processing.
• Ride-hailing app: Uber-style: API gateway, ride service, Redis geo cache, trip store, a Kinesis location stream feeding a Lambda matching engine, and Stripe payments.
• Video streaming: Netflix-style: a video CDN over S3 origin + Glacier archive, a catalog API, a continue-watching cache, and a playback-events analytics pipeline.
• E-commerce checkout: Amazon-style storefront: CDN with an edge function for header/redirect checks, WAF + ALB, a web tier, product search, a cart cache, an orders DB and inventory store (in a VPC), an async fulfilment queue, and Stripe.
• Serverless data pipeline: IoT-style ingestion: HTTP API to a buffering Lambda, a Kinesis stream, a processor Lambda writing to DynamoDB + an S3 lake, with Athena queries and a Glue catalog.
• URL shortener: A compact read-heavy service: CDN, API, a hot-links cache, a key-value store, and a click-analytics stream.
• Indie SaaS on Vercel: A small-team SaaS on managed PaaS: Vercel hosting + functions, Neon serverless Postgres, Auth0, Algolia search, Twilio SMS alerts, and Datadog observability.
• Mobile app on Firebase + AWS: Firebase Firestore + Auth for the mobile client, native BigQuery analytics export, and a thin AWS backend (API Gateway → Lambda → EventBridge) for the business logic Firebase alone can’t do.
• Community app on Supabase: A community platform on Supabase (Postgres + Auth + Realtime as one plan-priced backend), with Redis Cloud for session/rate-limit checks and direct SES for transactional email.
• Modern data stack: A Databricks + Snowflake lakehouse: CDC events land in S3, Databricks does the ETL/ML transform, Snowflake serves governed BI queries. Contrast with the AWS-native Glue/EMR/Redshift pipeline.
• Open-banking API backend: A partner-facing open-banking API: API Gateway (REST) with caching + a Cognito authorizer, a core-banking engine on EC2/EBS, RDS Proxy in front of Aurora, KMS + Secrets Manager as side-calls, and a Step Functions approval saga for wire/loan requests.
• VFX render farm: A submission API queues frame-render jobs onto AWS Batch, which schedules them across an EC2 fleet sharing FSx for Lustre scratch storage during the render.
• Polyglot microservices platform: Kong Gateway routes to three independently-owned services, each on the datastore its team chose: PlanetScale (Orders), MongoDB Atlas (Catalog), Tiger/TimescaleDB (Metrics) - plus a shared self-managed Redis and Amazon MQ for async order events.
• AI gateway (multi-provider LLM router): A query embedding (SageMaker) + vector search (OpenSearch) feed a router that splits evenly across OpenAI, Anthropic, and Bedrock - Bedrock reserved for traffic that must stay inside the AWS boundary.
• Industrial IoT + analytics: Device telemetry through IoT Core’s Rules Engine, dual-written to a hot path (MSK → Lambda → Timestream → CloudWatch) and a cold path (Firehose → S3 lake → Glue + EMR → Redshift → QuickSight).
• Product analytics platform: One Kafka event stream feeding two OLAP stores: Apache Pinot for the in-product analytics panel at high QPS, and ClickHouse for analyst queries and BI, loaded in batches of a thousand events per INSERT.
• Collaboration platform: A Notion/Slack-style product: AppSync realtime doc sync + WebSocket chat + Redis Streams presence (Realtime Layer), a DocumentDB/Neptune/MemoryDB/DynamoDB data tier (grouped VPC), and an App Runner integrations service flagged as tech debt.
• Enterprise data & ML orchestration: EventBridge Scheduler triggers an MWAA ETL DAG (extract → S3 lake → Redshift), which pings a legacy on-prem Dkron scheduler mid-migration and hands off to a separate Dagster ML asset pipeline once the warehouse load lands.
• Enterprise hybrid network: Global Accelerator + NLB + GWLB secure ingress to an ALB/Fargate/Aurora app tier, with VPC Endpoint, NAT/IGW, Storage Gateway, and a Direct Connect + Transit Gateway link to an on-prem legacy system.
• Multiplayer game backend: Self-managed game servers behind an NLB (not GameLift): ECS-on-EC2 session hosts, DynamoDB + DAX for player state, ElastiCache Memcached for the leaderboard, and Keyspaces for match history.

Full-scale systems

Production-scale designs. Start with a reference architecture if these look dense.

• Multi-region social platform: Active-active photo/social platform across two regions: geo-routed edge, full regional stacks, cross-region graph replication, and global tables for media index, sessions, recommendations, and moderation.

Interview practice

Classic interview problems, each built as a working architecture you can load and run.

• Rate limiter: Sliding-window rate limiting at the edge. A limiter fleet checks and increments a sharded Redis counter before requests reach the backend, with live-updatable rules and an async metrics pipeline.
• Distributed key-value store: A coordinator implements quorum reads/writes (W+R>N) against Keyspaces - the consistent-hashing ring, gossip membership, and vector clocks are internal to the managed Cassandra-compatible store. A scheduled anti-entropy worker reconciles divergent replicas.
• Unique ID generator: A stateless Snowflake-style ID generator - no per-request coordination, just a one-time machine-ID lease at cold start, with clock-drift monitoring so timestamps never move backwards.
• URL shortener: Cache-aside redirect reads (app servers → Redis → DB on miss), a dedicated base62 ID-generator on the write path, and an async click stream feeding an analytics lake.
• Web crawler: URL Frontier → HTML Downloader (+ DNS Resolver) → Content Storage + Parser → content dedup (checksum) and URL dedup (Bloom-filter role via Redis). A scheduler re-enqueues known pages for freshness.
• Notification system: A Notification Server fans out to one queue per channel (push/SMS/email) so a slow channel can’t back up the others - SNS for push, Twilio for SMS, SES for email - after checking each user’s opt-in settings.
• News feed system: A Fanout Service pushes new posts into followers’ feed caches on write (reading the social graph); a Feed Service assembles reads from the pre-computed cache + hydrated post content + CDN media.
• Chat system: An NLB (not ALB - connections are long-lived and stateful) fronts WebSocket chat servers, with a Redis presence tracker, a Cassandra-style message store, and push notifications for offline users.
• Search autocomplete: API servers read from an in-memory Trie Cache (falling through to a Trie DB); every query is logged and periodically re-aggregated into a rebuilt trie by an offline, scheduled Trie Builder.
• Design YouTube (upload + playback): Upload → original storage → a transcoding-queue-driven worker pool (multi-stage DAG: codecs, resolutions, thumbnails) → transcoded storage + a completion handler updating metadata, with playback served from CDN.
• Design Google Drive: A Block Server chunks/compresses/encrypts files into Block Storage, a Metadata DB tracks file/block/version relationships separately, a Notification Service syncs other clients on change, and a scheduled job tiers cold blocks to archival storage.
• Proximity service: A read-heavy Location-Based Service fans each search into 9 geohash-cell reads on a sharded Redis cache, a small Business Service handles CRUD and detail pages through an info cache, and a nightly batch rebuild is what makes owner edits visible next day.
• Nearby friends: Periodic pings over WebSocket fan out via per-user Redis Pub/Sub channels to ~40 online friends each, so delivery runs 40x the ping rate back onto the same socket tier (a Return edge closes the loop); the latest location lives only in a TTL cache and history is written off the hot path.
• Google Maps: Navigation loads precomputed routing tiles from object storage and prices every route against a Live Traffic store; that store is fed by a firehose of user location pings streaming through Kafka; map images serve straight from a CDN; and the tiles themselves are rebuilt offline, never edited live.
• Distributed message queue: Producers write to a partitioned, replicated broker cluster (MSK). Two consumer groups each drain the full log independently, one into durable storage and one into real-time analytics.
• Metrics monitoring & alerting: Agents push metrics through a collection stream into a time-series DB; a Query Service feeds dashboards while an Alert Manager evaluates rules against the same store and pages out.
• Ad click event aggregation: Click events are deduplicated once, then split into a real-time stream aggregator (fast, approximate) and a raw-event archive feeding a periodic batch reconciliation job (slow, accurate).
• Hotel reservation system: A cache-backed Search Service (staleness-tolerant) is split from a Reservation Service that writes straight to the primary DB (strong consistency, to avoid overbooking), then queues an async confirmation email.
• Distributed email service: Mail API → Mail Processor → spam/virus filter → delivery queue → a handler that fans out to attachment storage, metadata, search indexing, and SES for SMTP delivery.
• S3-like object storage: An Object API separates Metadata Store lookups from a Placement Service that routes bytes to replicated data nodes (S3 itself stands in for that layer), plus a background compaction job.
• Real-time gaming leaderboard: Score submissions go straight into a Redis sorted set (ZADD/ZRANGE/ZRANK) for O(log n) ranking; the database only sees a fraction, for durability.
• Payment system: A Payment Service checks an idempotency-key store before calling the PSP (Stripe) - so a retried request can’t double-charge - then writes the ledger and emits an event for reconciliation and fraud detection.
• Digital wallet: Balance-changing operations write straight to an ACID double-entry ledger DB, which then updates a balance cache and appends to transaction history - reads are cache-fast, writes are deliberately not.

Each of these problems also has a worked version, solved one twist at a time: Interview practice.

Open the SysPad canvas · Lessons on the individual services · Interview practice · Authoring format for AI agents