Module 7: Real-World Case Studies I

Why URL Shorteners Matter

A URL shortener converts a long URL like https://example.com/articles/2026/04/very-long-slug-that-nobody-wants-to-type into something like https://short.ly/a3Bx9k. That is the entire product. The simplicity is deceptive.

Bitly processes over 10 billion clicks per month and creates roughly 256 million short links monthly. The read-to-write ratio is roughly 40:1 at Bitly's scale, and can reach 100:1 or higher for popular link shorteners. This asymmetry is the defining characteristic of the system and drives every architectural decision.

Capacity Estimation

Before drawing any diagrams, pin down the numbers. Assume a service handling 100 million new URLs per month, with a 100:1 read-to-write ratio. Store URLs for 5 years.

A 7-character base62 key gives 3.5 trillion possible combinations. For 6 billion URLs, that is a collision probability so low you can ignore it with a proper generation strategy. But "so low you can ignore it" only holds if your generation strategy is actually proper. That is where the real design starts.

Short Key Generation: Three Approaches

There are three common strategies, each with distinct tradeoffs.

1. Random generation with collision check

Generate a random 7-character string. Check the database. If it already exists, generate another. Simple and stateless. The problem: as the keyspace fills, collision rate increases. At 6 billion keys out of 3.5 trillion, the probability of a collision on any single attempt is about 0.17%. That means roughly 1 in 600 writes needs a retry. Manageable, but not free.

2. Hash-based (MD5/SHA256 truncation)

Hash the long URL. Take the first 7 characters of the base62-encoded hash. Deterministic: the same input always produces the same output. The problem: different URLs can produce the same 7-character prefix. You still need a collision check, and you have lost the randomness that distributes keys evenly.

3. Counter-based with base62 encoding

Use a global auto-incrementing counter. Encode the counter value in base62. Counter 1 becomes 0000001. Counter 62 becomes 0000010. No collisions by definition. The problem: sequential keys are predictable. Anyone can guess the next URL. And you need a distributed counter that does not duplicate values across servers.

The counter approach is the most reliable at scale. Predictability is solved by adding a simple shuffle or XOR step before encoding. The distributed counter problem is solved by pre-allocating ranges: Server A gets IDs 1-1,000,000. Server B gets 1,000,001-2,000,000. No coordination needed until a range is exhausted.

High-Level Design

The system has two flows: URL creation and URL redirection. Both go through a load balancer to a stateless application layer, which talks to a cache and a database.

The database is a key-value store. The key is the short code. The value is the original URL plus metadata (creation date, expiration, user ID, click count). DynamoDB, Cassandra, or even a sharded MySQL table all work here. The access pattern is simple: point lookups by key. No range queries. No joins. This is where key-value stores shine.

Caching: The 80/20 Rule in Action

At a 100:1 read-to-write ratio, caching is not optional. It is the primary scaling mechanism. A small percentage of shortened URLs receive a disproportionate share of traffic. A viral tweet with a Bitly link might get millions of clicks in hours, while most links are clicked fewer than 10 times total.

Place a Redis or Memcached layer between the application servers and the database. Use an LRU (Least Recently Used) eviction policy. With even a modest cache, you can absorb 80-90% of read traffic without hitting the database.

Cache sizing math: if 20% of URLs account for 80% of traffic, and we have 6 billion total URLs, we need to cache roughly 1.2 billion entries. At 500 bytes each, that is 600 GB. Large, but well within what a Redis cluster can handle.

The 301 vs. 302 Decision

When a user clicks a short URL, the server responds with an HTTP redirect. The choice between 301 (Moved Permanently) and 302 (Found / Temporary Redirect) has real consequences.

A 301 tells the browser to cache the redirect. Next time the user clicks the same short URL, the browser redirects directly without contacting your server. This reduces server load but means you lose visibility into click analytics. You cannot count how many times the link was clicked because repeat visits never reach your servers.

A 302 tells the browser this redirect is temporary. Every click hits your server. You get accurate analytics, but at the cost of higher server load.

Bitly uses 301 for performance. Analytics are supplemented by JavaScript tracking on the destination page. Most URL shorteners with analytics features use 302 to ensure every click is counted.

Read vs. Write Traffic Distribution

The chart below illustrates why caching and read optimization dominate the architecture. For every URL created, the system handles dozens to hundreds of redirect requests.

Create and Redirect Flows

The two core operations in detail:

On a cache miss during redirect, the app server falls through to the database, fetches the mapping, populates the cache, and then redirects. The next request for the same key hits the cache.

Further Reading

• Designing URL Shortener Systems: From TinyURL to Bitly Scale, DEV Community
• System Design: Scalable URL Shortener Service like TinyURL, Sandeep Verma
• URL Shortener System Design, GeeksforGeeks
• Bitly, Wikipedia

The Problem: Personalized Timelines at Scale

When a user opens Twitter (now X), they see a feed of tweets from people they follow, ranked and ordered. This looks simple. It is not. At peak, Twitter handled 300,000 timeline read requests per second while ingesting around 4,600 new tweets per second (12,000 at peak). The system must assemble a personalized timeline for each of those 300K requests in under 200 milliseconds.

The core design question is deceptively simple: when User A posts a tweet, how does it appear in User B's feed? There are exactly two strategies, and Twitter has tried both.

Strategy 1: Fan-Out on Read (Pull Model)

When User B opens their timeline, the system queries all accounts B follows, fetches their recent tweets, merges them, ranks them, and returns the result. Every timeline request triggers a fresh computation.

This approach is simple and storage-efficient. You store each tweet once. But the read path is expensive. If User B follows 500 accounts, that is 500 lookups plus a merge-sort on every single request. At 300K requests per second, this does not scale.

Strategy 2: Fan-Out on Write (Push Model)

When User A posts a tweet, the system immediately writes a copy of that tweet's ID into the timeline cache of every follower. User B's timeline is pre-computed and sitting in memory (Redis) before B even opens the app.

This is what Twitter actually adopted. Each user's home timeline is stored as a Redis list of tweet IDs, replicated across 3 machines in a datacenter. The read path becomes a single Redis lookup. Fast. Predictable. Easy to cache.

The cost is write amplification. User A posts one tweet. If A has 5,000 followers, that single tweet generates 5,000 timeline writes. Twitter reported that this amplification inflated their 4,600 tweets/sec into 345,000 timeline writes per second.

The Celebrity Problem

Fan-out on write works beautifully until a celebrity posts. A user with 10 million followers generates 10 million timeline writes for a single tweet. At Twitter's scale, multiple celebrities tweet every second. The fan-out queue backs up. Timelines go stale. Users complain their feed is delayed.

This is not a theoretical problem. Twitter engineers confirmed that tweets from high-follower accounts could take more than 5 seconds to propagate to all followers. For breaking news from a journalist with millions of followers, that delay is unacceptable.

The Hybrid Approach

Twitter's actual production system uses a hybrid. Regular users (say, under 10,000 followers) use fan-out on write. Their tweets are pushed to follower timelines immediately. High-follower accounts are flagged. Their tweets are not fanned out. Instead, when User B requests their timeline, the system reads B's pre-computed timeline from Redis, then fetches recent tweets from any high-follower accounts B follows, merges them in, and returns the result.

The threshold is not fixed. Twitter uses a dynamic cutoff based on follower count and tweet frequency. An account with 5 million followers who tweets once a day is treated differently than one with 500,000 followers who tweets 50 times a day. The fan-out cost depends on both.

Cursor-Based Pagination

Timelines are paginated. The naive approach is offset-based: "give me tweets 20-40." This breaks when new tweets arrive between page requests. Tweet 20 on page 2 might be tweet 21 by the time the user scrolls. Items get duplicated or skipped.

Cursor-based pagination solves this. Instead of "give me page 2," the client says "give me 20 tweets older than tweet ID 1892347." The cursor is a pointer to the last item seen. New tweets arriving at the top of the timeline do not shift the cursor position. The user sees a consistent stream regardless of how fast new content arrives.

Storage Architecture

The timeline itself lives in Redis for fast reads. But the tweets themselves are stored in a persistent datastore. Twitter uses a MySQL cluster (sharded by user ID) for tweet storage. The Redis timeline contains only tweet IDs, not full tweet objects. When the client requests a timeline, the system reads the list of IDs from Redis, then hydrates them by fetching the full tweet data from the persistent store (with another cache layer in front).

This separation matters. Redis holds the ordering and personalization. The persistent store holds the source of truth. If a Redis node fails, timelines can be recomputed from the tweet store. Slow, but recoverable.

Further Reading

• The Architecture Twitter Uses to Deal with 150M Active Users, High Scalability
• Real-time Tweet Delivery Architecture at Twitter, HdM Stuttgart CS Blog
• Twitter's Tough Architectural Decision, Denny Sam
• System Design Primer: Twitter, Donne Martin

The Scale of Video

Over 500 hours of video are uploaded to YouTube every minute. That is 720,000 hours of new content per day. Netflix streams to over 260 million subscribers across 190 countries. At peak hours, Netflix alone accounts for roughly 15% of all downstream internet traffic in North America.

These numbers reveal something important about the architecture. Video is not a request-response problem. It is a pipeline problem. Raw footage enters one end, and optimized streams exit the other, tailored to thousands of different device and network combinations. Every step in between is a system design decision.

The Full Pipeline

From the moment a creator clicks "upload" to the moment a viewer presses play, the video passes through five major stages: upload, transcoding, storage, distribution, and playback.

Two parallel paths exist from the start. The video binary goes into object storage and the transcoding pipeline. The metadata (title, description, tags, thumbnail) goes into a relational database that feeds search and recommendation systems. These two paths are independent and should be treated as separate services.

Step 1: Chunked Upload

A raw 4K video file can easily be 10-50 GB. Uploading a 50 GB file as a single HTTP request is unreliable. Network interruptions, timeouts, and browser limits all conspire against you. The solution is chunked upload.

The client splits the file into chunks (typically 5-25 MB each). Each chunk is uploaded independently with a chunk index. The server reassembles them. If a chunk fails, only that chunk is retried. YouTube uses a resumable upload protocol that tracks which chunks have been received and allows the upload to continue from the last successful chunk after any interruption.

The upload target is object storage (S3, Google Cloud Storage). The raw file is stored as-is. This is the "source of truth" for the video. Everything downstream is a derived artifact.

Step 2: Transcoding

Raw uploaded video is not suitable for streaming. It may be in a codec the viewer's device cannot decode. It is almost certainly too large for mobile networks. Transcoding converts the raw video into multiple versions optimized for different devices and bandwidth conditions.

Netflix runs its transcoding pipeline on EC2 instances in AWS, processing petabytes of video data daily. Each video is encoded into multiple resolution and bitrate combinations called a "bitrate ladder."

Video Encoding Profiles

A single hour of uploaded video, transcoded into all six profiles, requires roughly 12.4 GB of storage. With 500 hours uploaded to YouTube every minute, that is over 6 TB of new processed video per minute. Per day, that exceeds 8.6 PB of new transcoded content.

Netflix takes this further with per-title encoding. Instead of using a fixed bitrate ladder, they analyze each video's complexity and generate a custom ladder. A slow dialogue scene needs less bitrate at 1080p than an action sequence. This optimization reduced Netflix's bandwidth requirements by roughly 50% without perceptible quality loss.

Step 3: Adaptive Bitrate Streaming

The viewer's bandwidth is not constant. It fluctuates as they move between Wi-Fi and cellular, as network congestion rises and falls, as other devices on the same network start or stop streaming. Adaptive Bitrate (ABR) streaming handles this dynamically.

The transcoded video is split into small segments, typically 2-10 seconds long. Each segment exists at every quality level. A manifest file (HLS uses .m3u8, DASH uses .mpd) lists all available segments and their quality levels. The video player on the client device monitors its download speed and buffer level, then requests the appropriate quality for each segment.

The quality switch happens at segment boundaries. If each segment is 4 seconds long, the player can adjust quality every 4 seconds. Shorter segments allow faster adaptation but increase the number of HTTP requests and the manifest file size. Longer segments are more efficient but slower to adapt.

Step 4: CDN Delivery

Serving video from a single origin datacenter does not work at global scale. A viewer in Jakarta requesting video from a server in Virginia would experience high latency and compete for bandwidth across undersea cables. Content Delivery Networks solve this by caching video segments at edge servers close to viewers.

Netflix operates its own CDN called Open Connect. Netflix embeds custom hardware appliances (called Open Connect Appliances, or OCAs) directly inside ISP networks. During off-peak hours, popular content is pre-positioned on these devices. When a subscriber presses play, the video is served from a box inside their own ISP's network, often within the same city.

YouTube uses Google's global network and edge caches. The principle is the same: move the data closer to the viewer. Popular videos are cached at many edge locations. Long-tail content (rarely watched videos) may only exist at a regional cache or the origin. The first viewer in a region pays the latency cost, and subsequent viewers benefit from the cache.

Metadata and the Relational Layer

While the video binary lives in object storage and CDNs, everything else about the video lives in a relational database. Title, description, upload date, view count, like count, comments, channel information, tags, categories, subtitles, and content moderation flags. This metadata drives search, recommendations, and the entire user interface.

YouTube uses a combination of MySQL (Vitess, their sharding middleware) and Bigtable for different metadata needs. The key insight: video content and video metadata are separate systems with separate scaling characteristics. Content is write-once-read-many with massive bandwidth needs. Metadata is read-heavy with complex query patterns (search, filter, sort, aggregate).

Further Reading

• High Quality Video Encoding at Scale, Netflix Tech Blog
• 2025 YouTube Statistics: Global Overview and Key Trends, Teleprompter.com
• Video Encoding and Quality Research, Netflix Research
• Adaptive Bitrate Streaming: What It Is and How ABR Works, Dacast

What Makes Chat Different

A chat application looks simple on the surface: User A types a message, User B receives it. But the engineering challenges are unique. Unlike a web application where the client initiates every interaction, a chat system must push messages to clients the moment they arrive. The server cannot wait for the client to ask. It must deliver proactively.

WhatsApp handles approximately 100 billion messages per day across 2 billion users, with only about 50 engineers. That efficiency comes from making sharp architectural choices and sticking with them.

Connection Model: WebSockets

HTTP is request-response. The client asks, the server answers. For chat, you need a persistent, bidirectional channel. WebSockets provide exactly this. After an initial HTTP handshake, the connection upgrades to a full-duplex TCP connection. Both sides can send data at any time without waiting for the other.

WhatsApp's original architecture used persistent TCP connections managed by Erlang processes. Each connected device maintains one process on a frontend server. No connection pooling. No multiplexing. One connection, one process. This sounds wasteful until you realize that Erlang processes are extremely lightweight (roughly 2 KB each) and the BEAM VM can handle millions of them on a single machine.

For a system design interview, WebSockets are the standard answer. The connection is established when the app opens and maintained as long as the user is active. A heartbeat mechanism detects dropped connections.

High-Level Architecture

Each chat server maintains WebSocket connections to a set of users. When User A sends a message to User B, Chat Server 1 publishes the message to a message queue. Chat Server 2 (where User B is connected) consumes the message and pushes it down User B's WebSocket. If User B is offline, the message is stored and a push notification is sent instead.

Message Delivery: Online Path

When both users are online and connected to the system, message delivery is straightforward but involves multiple guarantee checks.

Notice the two checkmarks. The first (sent) confirms the server received and stored the message. The second (delivered) confirms the recipient's device received it. WhatsApp adds a third state: read, triggered when the recipient actually opens the conversation. Each state is a separate acknowledgment flowing back through the system.

Message Delivery: Offline Path

The harder case. User B is not connected. Their phone is off, out of range, or the app is backgrounded. The message must still arrive eventually. This is store-and-forward.

When the message queue tries to deliver to Chat Server 2 and finds no active connection for User B, it triggers two actions. First, the message is already persisted in the message store (Cassandra), tagged as undelivered. Second, a push notification is sent through APNs (Apple) or FCM (Google) to wake the device and alert the user.

When User B comes back online and establishes a WebSocket connection, the chat server queries the message store for all undelivered messages for User B, sorted by timestamp, and pushes them down the connection. Once User B's device acknowledges receipt, the messages are marked as delivered.

Storage Decisions

Cassandra is the dominant choice for message storage because of its write performance and natural time-series partitioning. Messages within a conversation are stored in a single partition, ordered by timestamp. Reading a conversation is a single sequential scan of one partition. WhatsApp's engineering team has spoken about running Cassandra clusters handling 230,000 writes per second.

Group Chat: The Fan-Out Problem Returns

One-to-one chat is point-to-point delivery. Group chat is one-to-many. When User A sends a message to a group of 100 members, the system must deliver 99 copies (everyone except the sender). This is the same fan-out problem from Session 7.2, but at message-level granularity.

The approach: the chat server publishes the message to a group topic in the message queue. Each member's chat server subscribes to that topic. When the message arrives, each server pushes it to the connected members. Offline members get store-and-forward treatment as before.

WhatsApp caps groups at 1,024 members. This is not an arbitrary limit. It is a fan-out constraint. A message to a 1,024-member group generates 1,023 delivery operations. At WhatsApp's message volume, larger groups would create unsustainable write amplification.

End-to-End Encryption

WhatsApp uses the Signal Protocol for end-to-end encryption. The key principle: the server never sees plaintext messages. Messages are encrypted on the sender's device and decrypted only on the recipient's device. The server stores and forwards ciphertext.

The protocol uses X3DH (Extended Triple Diffie-Hellman) to establish a shared secret between two devices, and the Double Ratchet algorithm to generate a new encryption key for every single message. Even if an attacker compromises one message key, they cannot decrypt past or future messages. This property is called forward secrecy.

For system design purposes, encryption adds two constraints. First, the server cannot index or search message content (it is ciphertext). Features like server-side search require separate encrypted indexes. Second, multi-device support is complex because each device has its own key pair. Sending a message to a user with 3 devices means encrypting the message 3 times, once with each device's public key.

Presence and Typing Indicators

The "online" indicator and "typing..." status are presence features. They are ephemeral, high-frequency, and tolerance for staleness is high. Nobody cares if the "online" status is 5 seconds stale.

Presence is stored in Redis with a TTL. When a user's WebSocket sends a heartbeat, the TTL is refreshed. When the heartbeat stops (disconnect), the key expires automatically. Typing indicators are even more transient. They are sent as fire-and-forget messages through the WebSocket. No persistence. No retry. If the indicator is lost, the worst case is the recipient does not see "typing..." for a few seconds.

Further Reading

• How WhatsApp Handles 100 Billion Messages Per Day, ByteByteGo
• 8 Reasons Why WhatsApp Was Able to Support 50 Billion Messages a Day with Only 32 Engineers, System Design One
• Why Signal Protocol is Well-Designed, Praetorian
• Design WhatsApp System Design Interview, AlgoMaster

The Core Problem

A ride-hailing platform connects riders who need a car with drivers who have one. That sentence sounds simple. The engineering behind it is not. At Uber's scale, the system handles roughly 31 million trips per day, with 2 million online drivers sending GPS coordinates every 4 seconds. That produces around 500,000 location writes per second at peak.

The fundamental challenge is real-time spatial matching: given a rider's location, find the nearest available drivers within seconds. This is a search problem over constantly moving data points on a spherical surface.

Geospatial Indexing

You cannot query "find all drivers within 2 km" by computing the distance from the rider to every single driver. With 2 million online drivers, that brute-force approach would take too long and consume too many resources. Instead, the system partitions the Earth's surface into a grid of cells, assigns each driver to a cell based on their current coordinates, and only searches nearby cells when a match request arrives.

Three indexing systems dominate this space.

Geohash is the simplest. It encodes latitude and longitude into a single string by interleaving bits. Longer strings mean smaller cells. The problem: two points on opposite sides of a cell boundary can have completely different geohash prefixes, making boundary queries tricky.

Google S2 projects the Earth onto a cube, then uses a Hilbert curve to map 2D regions to 1D ranges. This preserves spatial locality better than geohash. Uber originally used S2 for their dispatch system.

Uber later developed H3, a hexagonal grid. Hexagons have a useful property: every neighbor is equidistant from the center. With squares or rectangles, diagonal neighbors are farther away than edge neighbors. In a city where people are constantly moving in all directions, hexagons minimize the quantization error. H3 supports 16 resolution levels, from continent-sized hexagons down to roughly 1 square meter.

The "k-ring" operation is critical. Given a cell, it returns all cells within k hops. For finding nearby drivers, you start with k=1 (the 6 immediate neighbors plus the center cell), fetch all drivers in those 7 cells, and expand the ring if you need more candidates.

High-Level Architecture

The Location Service is the hottest component. It must absorb 500K writes/sec and serve spatial queries with low latency. This service stores driver locations in memory, sharded by geographic region. It does not use a traditional database for the live location data. Persistent storage (for trip history, analytics) comes later via Kafka.

The Matching Service receives a ride request, queries the Location Service for nearby available drivers, ranks them by estimated time of arrival, and dispatches a request to the best candidate. If the driver declines, the system moves to the next candidate.

Trip State Machine

Every trip follows a strict lifecycle. State machines prevent invalid transitions (you cannot complete a trip that was never started) and make the system easier to reason about during failures.

Each state transition triggers events. "DriverAssigned" triggers a push notification to the rider. "InProgress" starts the fare meter. "Completed" triggers payment processing and receipt generation. The state machine is the backbone that coordinates all downstream services.

Write Load: The Numbers

Consider the scale calculation for driver location updates.

With 50,000 drivers updating every 3 seconds: 50,000 / 3 = ~16,667 writes per second. At Uber's global scale of 2 million drivers updating every 4 seconds: 2,000,000 / 4 = 500,000 writes per second. No single relational database handles this. The solution is an in-memory store (like Redis or a custom service), sharded by H3 cell ranges, with asynchronous persistence to durable storage.

Surge Pricing as a Reinforcing Loop

Surge pricing connects directly to the reinforcing loops from Session 0.4. When demand exceeds supply in a region, prices increase. Higher prices attract more drivers to that region (supply increases). Higher prices also discourage some riders (demand decreases). This is a balancing mechanism layered on top of a reinforcing signal.

But there is a reinforcing loop hiding underneath. When surge pricing activates, drivers from neighboring regions migrate toward the surge zone. This creates undersupply in those neighboring regions, which triggers surge pricing there, which causes further driver migration. The surge can propagate outward like a wave. Uber mitigates this with predictive positioning, incentivizing drivers to stay in areas where demand is expected to rise.

Further Reading

• H3: Uber's Hexagonal Hierarchical Spatial Index (Uber Engineering Blog)
• Geospatial Indexing Explained: A Comparison of Geohash, S2, and H3 (Ben Feifke)
• How Uber Finds Nearby Drivers at 1 Million Requests per Second (Ajit Singh)
• How Uber Serves over 150 Million Reads per Second from Integrated Cache (ByteByteGo)

The Core Problem

An e-commerce platform at Amazon's scale sells hundreds of millions of products across dozens of countries. On Prime Day 2023, Amazon processed over 375 million items in a single day. The catalog alone contains over 350 million SKUs. Behind the simple act of clicking "Buy Now" sits a distributed transaction that must coordinate inventory, payment, shipping, and notifications across multiple services, all while ensuring that two customers never buy the last unit of the same item.

Service Decomposition

A monolithic e-commerce application hits a wall quickly. The search team's deployment schedule differs from the payment team's. The inventory service has different scaling needs than the recommendation engine. Microservices let each team own their domain.

High-Level Architecture

The Checkout Flow: Inventory Locking

The critical moment is checkout. When a user clicks "Place Order," the system must reserve inventory, authorize payment, and create the order. If any step fails, the preceding steps must be rolled back. This is the Saga pattern (covered in Session 6.5).

Inventory is modeled with three numbers per SKU per warehouse: on_hand (physical stock), reserved (claimed by pending orders), and available (on_hand minus reserved). This prevents overselling without locking the entire row for the duration of a checkout.

The reservation step uses an optimistic approach. The SQL WHERE available >= qty clause acts as a guard. If two users try to buy the last item simultaneously, only one reservation will succeed because the second query will see available = 0 after the first transaction commits. The loser gets an "out of stock" response.

This is optimistic locking in practice. No explicit lock is held. Instead, the database's transactional guarantees ensure that the constraint check and the update happen atomically.

Payment: Exactly-Once Semantics

Payment is the one operation where "at least once" delivery can cost you real money. Charging a customer twice is worse than not charging them at all. The system must guarantee exactly-once processing.

The standard approach uses an idempotency key. The Order Service generates a unique key for each payment attempt and sends it with the charge request. The Payment Service stores this key. If the same key arrives again (due to a retry after a network timeout), the Payment Service returns the original result without processing a second charge.

On the provider side, payment finality relies on the webhook callback from the payment processor (Stripe, Adyen), not the synchronous API response. The synchronous response confirms the request was received. The webhook confirms the money moved. The Order Service should not mark an order as "paid" until the webhook arrives.

Search-Optimized Catalog

Product search is read-heavy. Users browse, filter, and search far more than they buy. The catalog uses Elasticsearch for full-text search and faceted filtering (brand, price range, rating, category). The source of truth for product data lives in DynamoDB. Changes propagate to Elasticsearch via a change data capture (CDC) stream.

This separation lets the search index be optimized for read patterns (denormalized, pre-aggregated facet counts) while the primary store maintains normalized data integrity.

Recommendation Engine

The "Customers who bought X also bought Y" feature is a collaborative filtering problem. At Amazon's scale, recommendations are precomputed offline using batch processing (Spark or equivalent) and stored in a fast key-value store (Redis, DynamoDB). When a user views a product, the service looks up precomputed recommendations by product ID. Real-time signals (what the user just clicked) are blended in at serving time via a lightweight model.

The key insight: recommendations are not computed on the fly. They are a read path. The heavy computation happens in a daily or hourly batch job.

Further Reading

• Architecting a Highly Available Microservices-Based Ecommerce Site (AWS Architecture Blog)
• Amazon System Design (CodeKarle)
• Build a Scalable E-commerce Platform: System Design Overview (DZone)
• Saga Pattern (Microservices.io, Chris Richardson)

The Core Problem

A notification system delivers messages to users across multiple channels: push notifications, email, SMS, and in-app messages. That sounds like a simple "send message" API. In practice, it is a delivery pipeline that must handle user preferences, rate limiting, priority ordering, retry logic, and channel-specific failure modes, all at scale.

When Shopify runs a flash sale and needs to notify 10 million users within an hour, the system must process roughly 2,800 notifications per second sustained, with bursts much higher. Each notification might fan out to multiple channels (push and email). The pipeline must not collapse under this load, and it must not spam users who opted out of marketing messages.

Notification Channels Compared

SMS is the most expensive by a large margin. At scale, SMS can cost $10,000 per day or more. A well-designed system uses SMS only for critical messages (OTPs, security alerts) and routes everything else through push or email. The user preference table is the first place to check, and cost is the second.

High-Level Architecture

The architecture separates concerns into stages. Producers submit notification requests. The API validates and deduplicates. The Preference Lookup determines which channels the user has enabled. The Priority Router assigns the notification to the correct queue. Workers consume from queues and deliver via third-party providers. Failed deliveries land in a Dead Letter Queue for retry or investigation.

Delivery Flow with Retry

The retry strategy uses exponential backoff with jitter. Without jitter, all failed notifications retry at the same instant, creating a thundering herd that overwhelms the downstream provider again. Adding random jitter (say, plus or minus 20% of the backoff interval) spreads retries over time.

Rate Limiting

Rate limiting operates at two levels. Per-user rate limiting prevents notification fatigue: no user should receive more than N push notifications per hour, regardless of how many services want to notify them. Per-channel rate limiting respects provider quotas: APNs and FCM impose rate limits, and exceeding them results in dropped messages or temporary bans.

A sliding window counter in Redis works well for per-user limits. The key is rate:{user_id}:{channel}:{hour}, incremented on each send. If the counter exceeds the threshold, the notification is either downgraded to a lower-priority channel or deferred to the next window.

User Preferences as the Routing Table

Each user has a preference record that determines what they receive and how. A simplified model:

{
  "user_id": "u_12345",
  "channels": {
    "push": true,
    "email": true,
    "sms": false
  },
  "categories": {
    "order_updates": ["push", "email"],
    "marketing": ["email"],
    "security": ["push", "sms", "email"]
  },
  "quiet_hours": { "start": "23:00", "end": "07:00", "timezone": "Asia/Jakarta" }
}

When the Notification API receives a security alert, it looks up the user's preferences, finds that security notifications go to push, SMS, and email, and fans out to all three channels. A marketing notification only goes to email. During quiet hours, non-critical notifications are deferred until the window opens.

This preference lookup is the single most important step in the pipeline. Without it, the system is a spam cannon. With it, the system respects user intent.

Handling Downstream Failures

What happens when the push notification service (APNs or FCM) goes down entirely? The system needs a fallback strategy. If push delivery fails after all retries, the system can automatically escalate to email (cheaper and more reliable for store-and-forward delivery). For critical notifications like OTPs, the fallback chain might be: push, then SMS, then email. The fallback logic lives in the worker, not the producer. Producers should not need to know about delivery infrastructure.

Further Reading

• Notification System Design: Architecture and Best Practices (MagicBell Engineering)
• Design a Scalable Notification Service (AlgoMaster)
• How to Design a Notification System: A Complete Guide (System Design Handbook)
• Designing a Notification System: Push, Email, and SMS at Scale (DEV Community)

The Core Problem

A smart parking system tracks the real-time availability of every spot in a parking facility and allows users to reserve spots before arrival. The physical world imposes constraints that purely digital systems do not have. A parking spot can only hold one car. Sensors can malfunction. A driver might park in a different spot than the one they reserved. The system must reconcile digital state with physical reality continuously.

For a mall with 500 parking spots across 3 floors, the numbers are modest. But the design patterns are the same ones used at airport scale (10,000+ spots) or city-wide smart parking networks (100,000+ spots across hundreds of facilities). The concurrency challenge surfaces even at small scale: weekend peak hours produce bursts of simultaneous booking attempts for the last available spots on a popular floor.

Data Model

The version field on the Spot entity is critical. It enables optimistic locking, which we will cover in detail below.

High-Level Architecture

The Availability Service maintains an in-memory count (via Redis) of available spots per floor, updated by both the Booking Service (when a reservation is made) and the IoT Gateway (when sensors detect occupancy changes). This cache enables sub-millisecond availability checks without querying the database.

Concurrent Booking with Optimistic Locking

The central design challenge: two users open the app at the same time, see the same spot listed as available, and both tap "Reserve." Only one should succeed.

Pessimistic locking (SELECT FOR UPDATE) would work but creates contention. During peak hours, many users compete for spots on the same floor. Holding row locks for the duration of a booking transaction (which includes payment) would serialize all bookings and destroy throughput.

Optimistic locking is the better fit. Each Spot row has a version column. The booking flow reads the current version, performs the reservation, and writes back only if the version has not changed.

The WHERE version = 5 clause is the guard. When User A's update commits, the version changes to 6. User B's update finds no row matching version = 5, so zero rows are affected. The Booking Service interprets zero affected rows as a conflict and returns an error to User B.

This approach requires no explicit locks. The database's row-level atomicity handles the race condition. The tradeoff: under very high contention (dozens of users competing for the same spot), the retry rate increases. In a parking system, this is rarely a problem because contention is spread across hundreds of spots.

IoT Sensor Integration

Physical sensors (ultrasonic, infrared, or magnetic) detect whether a car is physically present in a spot. These sensors communicate via MQTT to an IoT Gateway, which translates sensor events into system events.

The sensor data serves two purposes. First, it reconciles the digital state with reality. If a spot is marked "reserved" in the database but the sensor shows it has been physically occupied for 15 minutes past the reservation window, the system can auto-complete the booking. If a spot is marked "available" but the sensor shows a car parked there (someone parked without a reservation), the system marks it as occupied.

Second, sensor data provides real-time availability that is more accurate than the booking database alone. A driver might reserve a spot, arrive, and park in a different spot because the reserved one was physically blocked. The sensor layer catches this discrepancy.

Availability: Cache vs. Database

Users checking availability far outnumber users making bookings. The read-to-write ratio might be 100:1. Querying PostgreSQL for every "how many spots are available on Floor 2?" request would waste database capacity on simple counts.

Redis maintains atomic counters: avail:{lot_id}:{floor_id}. When a booking is confirmed, the counter decrements. When a booking is cancelled or a sensor detects a car leaving, the counter increments. The counter is the first thing the app checks. The database is only queried when the user selects a specific spot to reserve.

A periodic reconciliation job (every 5 minutes) compares Redis counters against the actual database counts and sensor states. If they drift (due to missed events or Redis restarts), the job corrects the cache. This is eventual consistency with a bounded staleness window.

Payment Integration

Parking payment follows the same patterns as e-commerce (Session 7.6). An idempotency key per booking prevents double charges. For time-based pricing (pay per hour), the system calculates the final amount when the driver exits, not when they enter. The booking record stores the start time. The exit event (sensor detects car leaving, or user taps "End Session") triggers the payment calculation.

Pre-authorization is useful for reservations. The system authorizes a hold on the user's payment method at booking time and captures the actual amount at exit. If the user cancels before arriving, the hold is released.

Further Reading

• How to do distributed locking (Martin Kleppmann)
• PostgreSQL MVCC and Concurrency Control (PostgreSQL Documentation)
• MQTT: The Standard for IoT Messaging (mqtt.org)
• Designing a Parking Lot System (Design Gurus)