HardCake Shop · Part 4

Cake Shop 4 - Real-Time & Resilience

WebSocketsMessage QueuesMonitoringReplicationConsistency

This challenge builds on Cake Shop 3 - Going International. Complete it first for the best experience.

Problem Statement

Sweet Crumbs Bakery now operates at massive scale. Maya wants two new capabilities:

1. Real-time order tracking - customers see live updates as their order moves through preparation, baking, quality check, packaging, and delivery. Kitchen staff use a live dashboard that updates instantly when new orders arrive.

2. Disaster resilience - the system must survive an entire cloud region going offline without losing orders or causing more than 30 seconds of customer-facing downtime.

This requires designing a real-time event pipeline, a WebSocket layer for push updates, and a multi-region failover strategy with data consistency guarantees.

What You'll Learn

Add real-time order tracking, kitchen displays, and survive an entire region going down. Build this architecture under realistic production constraints, then validate tradeoffs in the design lab simulation.

WebSocketsMessage QueuesMonitoringReplicationConsistency

Constraints

Concurrent WebSocket connections~100,000
Order event latency< 2 seconds end-to-end
Failover time (region down)< 30 seconds
Data loss on failoverZero (RPO = 0)
Total DAU~5 million
Availability target99.99%
ApproachClick to expand

How to Approach

Clarify requirements: The monolith is getting hard to maintain. Teams want to deploy independently. Identify natural seams: product catalog, inventory, orders, payments, users.

Estimate scale: 1M+ DAU. Individual services need to scale independently -- the product catalog service gets 100x more reads than the payment service.

Pick components:

  • API Gateway as the single entry point (routing, auth, rate limiting)
  • Separate microservices for each domain: product, inventory, order, payment, user
  • Each service owns its own database (database-per-service pattern)
  • Message queue for async communication between services (order -> inventory -> payment)

Key tradeoffs to discuss:

  • Service boundaries: split by business capability, not by layer (not frontend/backend/database)
  • Database per service: strong isolation but cross-service queries require API calls or event streams
  • Distributed transactions: use saga pattern when an operation spans multiple services
  • Operational complexity: 5 services x (deploy + monitor + debug) vs 1 monolith

Learn the Concept

Practice Next

Reference SolutionClick to reveal

Decompose the monolith into microservices along business boundaries: Product, Order, and Payment services each own their database. The API Gateway handles routing, auth, and rate limiting. Order -> Payment communication is async via message queue using the saga pattern. Each service can now scale, deploy, and fail independently.