Online Food Delivery Platform — System Design 

1) Use Case & Problem Context

Users should be able to:

• Browse restaurants near them

• View menus (with frequent changes)

• Build carts and see accurate pricing (tax/fees/promos)

• Place orders and pay

• Restaurant accepts or rejects (out of stock, substitutions)

• Dispatch a courier and track delivery live

• Handle spikes (lunch/dinner), refunds, cancellations, fraud

Key challenges:

• High traffic bursts

• Menu updates and item availability uncertainty

• Distributed order lifecycle (multi-step workflow)

• Real-time courier tracking

• Reliability + idempotency (retries must not double-charge)

---

2) Core Requirements

Functional

• Restaurant discovery by location

• Menu browse (versioned)

• Cart pricing (coupons, taxes, fees, tips)

• Place order + payment authorization

• Restaurant accept/reject + substitutions

• Dispatch courier + ETA

• Live tracking and notifications

• Cancellations and refunds

Non-Functional

• Low latency for browse/search

• High availability for ordering/payment

• Eventual consistency acceptable for tracking (seconds)

• Strong observability and fraud controls

• Scalable dispatch matching

---

3) High-Level Architecture

Services

• Catalog/Search Service: restaurants + menus by geo

• Cart/Pricing Service: cart + price breakdown engine

• Order Service: order state machine + saga orchestration

• Payment Service: auth/capture/refund

• Restaurant Adapter: connects to restaurant POS/tablet

• Dispatch Service: courier matching, offers, surge

• Geo/Tracking Service: live courier location ingestion + queries

• Notification Service: SMS/push/email + in-app events

• Fraud/Risk Service: suspicious orders, test orders, chargeback defense

Text diagram

User App
  |
  +--> Catalog/Search -----> Cache + Search Index
  |
  +--> Cart/Pricing --------> Pricing Rules/Promos
  |
  +--> Order Service (Saga)
          |--> Payment (Auth/Capture/Refund)
          |--> Restaurant Adapter (Accept/Reject/Substitute)
          |--> Dispatch Service (Courier match)
          |--> Notifications (Status updates)
                          |
                          +--> Tracking/Geo (live map)

---

4) Catalog & Search Design

What we store

• Restaurant metadata: geo, cuisine, rating, hours, price range

• Menus: items, prices, modifiers, menu_version

• Availability often dynamic (restaurants change stock)

Indexing approach (fast browse)

• Denormalized searchable catalog by geo cells (city/zipcode/geohash)

• Filters: cuisine, price, open now

• Cache hot geo areas (downtown) heavily

Why denormalize?
Browse/search needs to be extremely fast and can tolerate slightly stale data.

---

5) Cart & Pricing (Where correctness matters)

Cart rules

• Cart belongs to a restaurant (usually one restaurant per order)

• Pricing is computed using a pricing engine

  • taxes, delivery fee, service fee, surge fee

  • discounts/coupons

  • tips (optional)

  • rounding rules

Menu changes handling

Menus change frequently, so cart must reference:

• restaurant_id

• menu_version

• item SKU + selected modifiers

On checkout:

• validate SKU still valid

• reprice if menu_version changed

• show user changes clearly

---

6) Order Lifecycle Using Saga (Core of the system)

Order Saga (typical states)

CreateOrder (PENDING)
  -> PaymentAuth
  -> RestaurantAccept
  -> Dispatch
  -> CourierEnroute
  -> Delivered

Why Saga?

Because ordering spans multiple systems:

• Payments

• Restaurant acceptance

• Dispatch/couriers

Sagas allow:

• step-by-step progression

• compensations (refund/cancel) if a step fails

Compensation examples

• Payment authorized but restaurant rejects → void/refund

• Dispatch fails (no couriers) → cancel + refund

• Courier cancels mid-way → re-dispatch or cancel

---

7) Ordering Data Flow (Step-by-step)

A) Place order

1. POST /order {cart_id, payment_method}

2. Order Service creates order=PENDING

3. Calls Payment → authorize

4. Sends order to restaurant → accept/reject

5. If accepted → Dispatch service assigns courier

6. On courier assignment → status updates and tracking enabled

7. On delivered → Payment capture + final receipt

Text diagram

Checkout
  |
  v
Order Service
  |
  +--> Payment Auth (hold money)
  |
  +--> Restaurant Accept (confirm items/substitutions)
  |
  +--> Dispatch Courier
  |
  +--> Tracking + Notifications
  |
  +--> Capture on Delivered

---

8) Dispatch & ETA (Matching couriers)

Matching approach (high level)

• Partition space into geo cells

• Maintain couriers in nearby cells with:

  • last location

  • capacity / current load

  • status

• Score candidates by:

  • distance to restaurant

  • estimated pickup time

  • courier load / rating

  • delivery SLA

Surge handling

When demand > supply:

• increase delivery fees

• batch offers to couriers

• expand search radius / relax constraints

Dispatch flow

1. Order ready-for-dispatch

2. Find eligible couriers near restaurant

3. Send offers (auction-like)

4. First accept wins → assignment created

---

9) Live Tracking (Real-time map)

How it works

• Courier app sends location updates every few seconds

• Ingest into Geo store (Redis GEO / TSDB)

• Tracking API reads latest locations and returns route status

Tracking flow

Courier App -> Location Updates -> Geo Store
Customer App -> GET /track/{order_id} -> Geo Store -> Map UI

Consistency:

• Eventual (a few seconds delay acceptable)

---

10) Notifications

Send updates to:

• Customer (push/SMS): order accepted, courier assigned, arriving, delivered

• Restaurant: new order ticket/print

• Courier: new assignment, pickup details

Important: notifications should be asynchronous and retryable.

---

11) Fraud & Safety (High level)

Common fraud patterns:

• Fake/test orders

• Stolen cards / chargebacks

• Abnormal routes / courier collusion

• Coupon abuse

Controls:

• device fingerprinting + velocity limits

• risk scoring before payment capture

• suspicious order hold / manual review

• courier route anomaly detection

---

12) Data Model (Simple)

restaurants

• (id, geo_cell, hours, cuisine, menu_version)

menu_items

• (restaurant_id, sku, price, modifiers, stock?)

orders

• (id, user_id, restaurant_id, items[], price, status, created_at)

couriers

• (id, status, last_location, capacity)

assignments

• (order_id, courier_id, status, created_at)

events (optional)

• (order_id, event_type, ts, payload) for audit/debug

---

13) APIs (Blog-level)

Catalog

• GET /restaurants?geo=...&filters=...

• GET /restaurants/{id}/menu

Cart

• POST /cart {restaurant_id, items, coupon}

• POST /cart/{id}/price → price breakdown

Order

• POST /order {cart_id, payment}

• GET /order/{id}

Dispatch (internal)

• POST /assign {order_id}

Tracking

• GET /track/{order_id}

---

14) Mermaid Diagram (Optional)

flowchart LR
User --> API[API Gateway]
API --> Catalog[Catalog/Search]
API --> Cart[Cart/Pricing]
API --> OrderSvc[Order Service]

OrderSvc --> Pay[Payments]
OrderSvc --> Rest[Restaurant Adapter]
OrderSvc --> Dispatch[Dispatch Service]
Dispatch --> Geo[(Live Locations Store)]
Dispatch --> CourierApp[Courier App]
OrderSvc --> Notify[Notifications]
User <-->|track| TrackAPI[Tracking API]
TrackAPI --> Geo

---

15) Interview Talking Points (What to highlight)

• Saga and compensations (refund on failure)

• Idempotency (avoid double charge/order)

• Dispatch strategy + surge handling

• Menu versioning + substitutions workflow

• Cursor-based tracking updates

• Fraud signals (coupon abuse, route anomalies)

• Scalability: cache hot geo cells, async notifications

---

16) One-Minute Interview Summary (Memorable)

“Browse uses a denormalized geo-indexed catalog with heavy caching.
Checkout goes through cart pricing and then an order saga: payment auth → restaurant accept → dispatch courier → deliver → capture payment.
Dispatch uses geo-cell matching and scoring, and live tracking is powered by frequent courier location updates into a geo store.
Failures are handled by saga compensations like cancel + refund, and we add risk scoring and rate limits to reduce fraud.”

 WhatsApp System Design (High-Level)

1️⃣ What Problem Does WhatsApp Solve?

WhatsApp enables:

• Real-time messaging

• 1:1 and group chats

• Low latency delivery

• Offline message sync

• Strong privacy (End-to-End Encryption)

The system must work reliably for billions of users, across:

• Mobile networks

• Intermittent connectivity

• Different devices and regions

---

2️⃣ Core Requirements

Functional

• Send and receive messages

• Support 1:1 and group chats

• Message ordering

• Delivery & read receipts

• Presence (online/offline) and typing indicators

• Media sharing (images, videos, documents)

Non-Functional

• Very low latency

• High availability

• Massive scalability

• Message durability

• Privacy and security

---

3️⃣ High-Level Architecture

Mobile Client
    |
    v
WebSocket Gateway
    |
    v
Message Service
    |
    +--> Message Store (durable)
    |
    +--> Fan-out to Online Users
    |
    +--> Push Notifications (offline users)

Supporting systems:

• Redis → presence & typing

• Object Storage (S3/GCS) → media

• APNs / FCM → mobile push notifications

---

4️⃣ Message Flow (Send → Receive)

Step 1: Send

• User sends a message

• App sends message to server via WebSocket

• Server stores message first (durability)

Step 2: Deliver

• If recipient is online → push instantly

• If recipient is offline → send push notification

Step 3: Sync

• When offline user opens app:

  • Client fetches missing messages

  • Uses last seen message id or sequence

---

5️⃣ Message Storage & Ordering

How messages are stored

• Messages are stored once per chat (conversation)

• Each message gets a sequence number

• Sequence numbers guarantee ordered delivery

Conversation A:
  seq 1 → "Hi"
  seq 2 → "Hello"
  seq 3 → "How are you?"

Why not global ordering?

• Global ordering does not scale

• Ordering is required only inside a chat

---

6️⃣ Group Chats (Important)

How group messages work

• Message stored once in group chat

• Server sends to:

  • All online members immediately

  • Offline members via pull on reconnect

Messages are not synced continuously to all phones.

This avoids:

• Battery drain

• Network waste

• Write amplification

---

7️⃣ Fan-out Explained (Simply)

Fan-out = deliver one message to many users

In WhatsApp:

• Small groups → push to all online members

• Large groups → push online, pull for offline

WhatsApp uses a hybrid fan-out model.

---

8️⃣ Offline Messaging

• Messages always stored on server

• Offline users receive:

  • Push notification (wake-up)

• On reconnect:

  • Client fetches messages after last seen id

GET /history?after=last_message_id

---

9️⃣ Presence & Typing Indicators

These are ephemeral states:

• Stored in Redis

• Have short TTL (seconds)

Examples:

• Online / Offline

• “Typing…”

They are not persisted in message storage.

---

🔟 Media (Images, Videos, Files)

Media is handled separately from messages:

1. Client uploads media to object storage using a pre-signed URL

2. Message contains only media reference

3. Media is downloaded directly from storage/CDN

This keeps messaging fast and scalable.

---

1️⃣1️⃣ End-to-End Encryption (E2E)

WhatsApp uses E2E encryption:

• Messages encrypted on sender’s device

• Decrypted only on recipient’s device

• Server stores encrypted content only

Trade-offs:

• Server cannot read messages

• Searching messages is harder

• Abuse detection is limited

---

1️⃣2️⃣ Reliability & Safety

• Messages are acknowledged after persistence

• Retries handled by client using message IDs

• Duplicate messages avoided using idempotency

• Abuse handled via metadata & rate limiting

---

1️⃣3️⃣ Why This Design Scales

• WebSockets for real-time delivery

• Store once, deliver many

• Pull-based offline sync

• Separation of:

  • messages

  • presence

  • media

• Eventual consistency is acceptable

---

1️⃣4️⃣ Interview Talking Points (Key)

• Store message before delivery

• Per-chat ordering, not global

• Push for online, pull for offline

• Fan-out trade-offs in group chats

• Redis for ephemeral state

• Object storage for media

• E2E encryption trade-offs

---

1️⃣5️⃣ One-Line Summary (Interview Gold)

WhatsApp stores each message once, pushes to online users in real time, and lets offline users fetch messages when they reconnect, all while preserving per-chat ordering and strong privacy.

 

Social Media Feed System Design (Timeline) — High Level

1) Use Case & Problem Context

We need to serve a fresh, ranked timeline for each user that blends:

• Posts from followed users

• Ads

• Recommended / suggested content

Key challenges:

• Low-latency feed reads (most traffic is reads)

• Celebrity/high-fanout accounts (millions of followers)

• Ranking + personalization

• Spam/abuse (bot posts, engagement manipulation)

---

2) Core Requirements

Functional

• Users create posts (POST /post)

• Users fetch their feed (GET /feed?cursor=...)

• Support pagination, freshness, and ranking

• Mix organic + ads + recommendations

Non-Functional

• Very low read latency (P95/P99)

• Scalable fan-out strategy

• Eventual consistency acceptable (seconds)

• Strong abuse controls and observability

---

3) High-Level Architecture (Text Diagram)

                (Write Path)
Client -> Post API -> Post Store -> Event Bus -> Fanout Workers
                                       |
                                       +--> Safety/Spam Checks
                                       |
                                       +--> Timeline Store/Cache (precomputed)

                (Read Path)
Client -> Feed API -> Timeline Cache/Store -> Ranker -> Media CDN -> Response
                              |
                              +-> For celebrities: On-demand pull of posts
                              |
                              +-> Feature Store (affinity/engagement signals)
                              |
                              +-> Ads + Recommendations mixer

---

4) Data Flow (Step-by-Step)

A) Write Path: Creating a Post (Ingest)

Goal: Store the post once, distribute it efficiently, and keep system safe.

Flow

1. User calls POST /post

2. Post is written to Posts DB (source of truth)

3. Emit event to Event Bus: POST_CREATED

4. Run spam/safety checks

   • immediate checks (rate limits, known bad domains)

   • async ML checks (spam, nudity, policy)

5. Update indexes:

   • author -> posts index (fast author feed)

   • engagement logs start empty

Why event bus?

• Decouples ingest from fanout and ranking

• Makes the system resilient and scalable

---

B) Fan-out Strategy (Push vs Pull)

This is the most important design decision.

Option 1: Push model (Fan-out-on-write)

For “normal” accounts:

• When an author posts, we push that post into followers’ timelines.

✅ Fast reads
✅ Feed can be mostly precomputed
❌ Can explode for celebrities

Option 2: Pull model (Fan-out-on-read)

For “celebrity / high-fanout” accounts:

• Do NOT push to all followers.

• Instead, followers’ feed pulls celebrity posts at read time.

✅ Avoid massive writes
✅ Scales for high-fanout
❌ Slightly heavier reads

Recommended approach: Hybrid (Industry standard)

• Push for normal accounts

• Pull for high-fanout accounts

• Threshold based on follower count or write amplification cost

Interview line: “Hybrid fanout is the practical choice—push for most users, pull for celebrities.”

---

5) Read Path: Fetching the Timeline

Endpoint:

• GET /feed?cursor=...

Flow

1. Feed API reads from Timeline Cache/Store

   • precomputed items (push model)

2. Also fetches “pull sources”

   • recent posts from celebrity accounts the user follows

3. Combine candidates into a working set

4. Rank the candidates using an online ranker

5. Blend:

   • organic posts

   • ads

   • recommended content

6. Hydrate media refs using Media CDN

7. Return results + next cursor

Read path diagram

GET /feed?cursor
   |
   v
[Timeline Cache] + [Celebrity Pull]
         |
         v
     Candidates
         |
         v
     Ranker  <--- Feature Store
         |
         v
Mixer (Organic + Ads + Recs + Constraints)
         |
         v
Hydrate Media -> Response (items + cursor)

---

6) Ranking (High-Level)

Ranking decides “what appears first”.

Inputs (features)

• Recency (newer posts higher)

• Affinity (how close user is to author)

• Engagement probability (likes/comments history)

• Content type (photo/video/text)

• Negative signals (spam, low-quality, repetitive)

Feature Store

To keep ranking fast:

• Precompute stable signals (affinity, historical engagement)

• Cache them in a Feature Store (Redis/online store)

• Online ranker just “looks up” features

Blending constraints (important in interviews)

• Freshness guarantees (don’t show all old posts)

• Diversity (avoid 10 posts from same author)

• Content mix (video/photo/text)

• Ads spacing rules

---

7) Spam & Safety Controls

Spam and abuse must be handled early and continuously.

On ingest (post-time)

• Rate limit posting

• Reputation scoring (new account, suspicious domains)

• ML classifiers (spam, policy violations)

• Shadow banning / quarantine queue

On engagement (like/comment anomalies)

• Detect bot-like behavior and engagement spikes

• Downrank suspicious posts

• Block/limit repeat offenders

Interview line: “Safety is part of the pipeline—both at ingest and via engagement anomaly detection.”

---

8) Data Model (Simple)

Tables (conceptual):

• posts(id, author, ts, body, media_refs, visibility)

• follows(u, v, ts) // u follows v

• timelines(user, post_id, ts, source)

  • source: pushed vs pulled candidate vs ad vs recommendation

• engagements(user, post_id, type, ts)

  • type: like/comment/share/view

---

9) APIs

• POST /post → create a post

• GET /feed?cursor=... → main timeline

• GET /u/{id}/feed?cursor=... → user profile feed (author’s posts)

---

10) Pagination (Cursor-based)

Use cursor pagination (not offset) to handle:

• Changing ranking

• New posts arriving

• Large timelines

Cursor typically encodes:

• last seen timestamp

• last seen rank score

• last seen post id

---

11) Benefits

• Low latency feed reads via precomputed timelines

• Scales to celebrity accounts using pull strategy

• Supports personalization + ads

• Built-in safety and abuse resistance

• Clean separation: ingest, fanout, ranking, delivery

---

12) Interview Talking Points (What to emphasize)

• Push vs Pull fanout (+ hybrid approach)

• Celebrity problem (write amplification)

• Ranking inputs + feature store

• Cursor-based pagination

• Ads blending and constraints

• Spam/abuse: shadow bans, rate limits, anomaly detection

• Tradeoffs: freshness vs latency vs consistency

---

Whiteboard-Style Summary (30 seconds)

POST: Post API -> Posts DB -> Event Bus -> Fanout (push normal users)
                                 |
                                 +-> Safety checks

GET: Feed API -> Timeline cache + Celebrity pull -> Ranker -> Blend -> Media -> Response

 

Notification Service at Scale (Email/SMS/Push/In-App)

1) Use Case & Problem Context

We need to send notifications to millions of users across multiple channels:

• Email, SMS, Push, In-app

The system must support:

• Templates + personalization (e.g., {name}, {orderId})

• Localization fallback

• User preferences (opt-in/out)

• Quiet hours + frequency caps

• Retries with exponential backoff

• Provider failover (if one provider is down)

• Delivery status via provider webhooks

• Observability (success rate, bounces, latency)

---

2) High-Level Architecture (Text Diagram)

          +------------------+
          |   Client Apps    |
          +--------+---------+
                   |
                   v
            +------+------+
            | Notify API  |   POST /notify
            +------+------+
                   |
              create job
                   |
                   v
            +------+------+
            | Job Queue   |  (Kafka/SQS/Rabbit)
            +------+------+
                   |
                Fan-out
                   v
   +---------------+------------------+
   | Fanout Workers (per recipient)   |
   +---------------+------------------+
        |           |            |
        v           v            v
   Prefs Store   Template      Send Queue
   (opt-out,     Render        (per channel)
   quiet hours)                  |
                                 v
                      +----------+----------+
                      | Channel Providers    |
                      | Email / SMS / Push   |
                      +----------+----------+
                                 |
                               Webhooks
                                 v
                           Delivery Events
                         (status + metrics)

Key principle:
✅ Redirect hot path? (not relevant here)
✅ For notifications: API should be fast and async; heavy work happens in workers.

---

3) Core Data Flow

A) Send flow

1. Client calls POST /notify

2. Service creates a Send Job

3. Enqueue tasks per recipient per channel

4. Fanout worker checks:

   • preferences

   • quiet hours

   • dedupe/idempotency

5. Render template

6. Route to provider (failover if needed)

7. Persist delivery status

8. Retry with backoff if transient error

9. Move to DLQ if permanently failing

B) Status flow

1. Provider calls webhook: delivered/bounced/failed

2. Store delivery event and update metrics

---

Notes (What to say in interviews)

• Separate hot path vs cold path: API returns quickly; workers do heavy work.

• Fan-out: convert one job into many tasks (per user/channel).

• Preferences first: opt-out + quiet hours should skip early.

• Provider failover: try next provider on transient failures.

• Retries + DLQ: exponential backoff + poison message handling.

• Idempotency: dedupe key prevents duplicates.

 

API Rate Limiter – System Design 

1️⃣ Problem Statement

We need an API Rate Limiter to:

• Protect APIs from abuse

• Ensure fair usage per tenant/user/route

• Allow bursty traffic with a steady average

• Work in Kubernetes + multi-replica + multi-region

• Make decisions with very low latency

• Degrade gracefully if Redis or control plane fails

---

2️⃣ High-Level Idea (One-Line)

Rate limiting is an edge decision problem — keep it fast, local, and predictable.

---

3️⃣ Where Rate Limiting Happens

Client
  |
  v
[API Gateway / Ingress]
        |
        v
 [Rate Limiter]
        |
   (allow / deny)
        |
        v
 [Backend Service]

Best practice

• Enforce at the edge first (Gateway / Ingress)

• Optional: Sidecar / mesh for fine-grained internal APIs

---

4️⃣ Algorithm Choice (Keep It Simple)

✅ Token Bucket (Recommended)

• Allows bursts

• Maintains steady average rate

• Easy to reason about

❌ Sliding Window

• More accurate

• Heavier on storage and compute

• Usually overkill

👉 Interview tip

“I use token bucket for RPS and fixed window for daily/monthly quotas.”

---

5️⃣ Storage & Atomicity

Redis + Lua (Authoritative Check)

Key: rl:{tenant}:{route}
Value: { tokens_remaining, last_refill_time }

Lua script does atomically:

• Refill tokens based on time

• Deduct request cost

• Return allow/deny + remaining tokens

⚠️ Important Fix

If you use INCR + EXPIRE, that is fixed window, not token bucket.
➡️ Fix: Store tokens + refill timestamp and calculate refill in Lua.

---

6️⃣ Request Data Flow (Hot Path)

1. Request hits Gateway
2. Extract key (tenant / route / method)
3. Check local in-memory bucket (optional)
4. Redis Lua check (authoritative)
5. Allow → forward
6. Deny → 429 response

Client
  |
  v
[Gateway]
  |
  v
[Limiter] ---> Redis (Lua)
  |
  +--> 200 OK → Service
  |
  +--> 429 Too Many Requests

---

7️⃣ Multi-Region Strategy (Choose One)

Option A – Home Region (Recommended)

Tenant → fixed region → single Redis cluster

• Strong fairness

• Simple reasoning

Option B – Eventual Consistency

Region A Redis  ← async merge → Region B Redis

• Best latency

• Small temporary overshoot allowed

👉 Interview answer

“If fairness is critical, route tenants to a home region.
If latency matters more, accept small overshoot with eventual consistency.”

---

8️⃣ Failure Handling (Very Important)

Redis Down

• Default: Fail-open + local limiter

• Critical APIs: Fail-closed (payments/admin)

Control Plane Down

• Use last known policy

• Alert if policy is stale

---

9️⃣ Kubernetes Integration (Summary)

Option	Use Case
NGINX Ingress	Simple IP/path limits
Kong + Redis	Per-tenant / header-based limits
Envoy / Istio	Local + global rate limiting
Custom CRD	Enterprise policy management

---

🔟 Rate Limit Response

Always return standard headers:

X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After

Denied response:

HTTP 429 Too Many Requests

---

1️⃣1️⃣ What to Fix / Improve (Key Section)

✅ Fix 1: Use real Token Bucket

Replace window counters with token + refill timestamp.

✅ Fix 2: Add local limiter

Use in-memory bucket to reduce Redis load and hot keys.

✅ Fix 3: Decide multi-region policy clearly

Don’t mix strong consistency and CRDT casually.

✅ Fix 4: Define fail-open vs fail-closed per endpoint

Availability vs protection trade-off must be explicit.

---

1️⃣2️⃣ Text Diagram – Complete Flow

Client
  |
  v
[Ingress / Gateway]
  |
  v
[Rate Limiter]
   |        |
   |        v
   |     Redis (Lua)
   |
   +--> Allow → Service → 200
   |
   +--> Deny  → 429

---

1️⃣3️⃣ One-Minute Interview Explanation

“I enforce rate limiting at the gateway using a token bucket algorithm.
Each request checks a local bucket first, then Redis via a Lua script for atomic refill and decrement.
For multi-region, I either route tenants to a home region for strict fairness or allow small overshoot with eventual consistency.
On Redis failure, I fail-open with local limits by default and fail-closed only for critical APIs.”

---

✅ Final Outcome

• Predictable fairness

• Low-latency decisions

• Redis protected from overload

• Clear failure semantics

• Easy Kubernetes integration

---