EasyCake Shop · Part 1

Cake Shop 1 - Going Online

DatabasesAPI Design

Problem Statement

Sweet Crumbs Bakery is a beloved neighborhood cake shop that has been taking walk-in orders for 15 years. The owner, Maya, wants to launch a simple website where customers can browse the catalog, place orders, and pay online.

The site needs a product catalog (≈200 items), a shopping cart, and a checkout flow that records orders in a database. Maya expects about 10,000 unique visitors per day, with peaks on Friday evenings and Saturday mornings (roughly 3× the average).

Your job is to design the system architecture that can reliably serve this traffic, store order data safely, and keep the site responsive (< 500 ms page loads).

What You'll Learn

A small bakery wants to launch a website for online orders. Design the backend for ~10 k daily visitors. Build this architecture under realistic production constraints, then validate tradeoffs in the design lab simulation.

DatabasesAPI Design

Constraints

Daily active users~10,000
Peak multiplier3× average (Fri-Sat)
Catalog size~200 products
Page load target< 500 ms
Availability target99.5%
BudgetLow - single small team
ApproachClick to expand

How to Approach

Clarify requirements: Small e-commerce shop, ~10k daily visitors, 3x peak on weekends. Product catalog (~200 items), shopping cart, checkout, order history.

Estimate scale: 10k DAU / 86,400s ~= 0.12 RPS average. 3x peak ~= 0.35 RPS. A single server handles this trivially.

Pick components:

  • Web browser -> DNS (domain resolution) -> CDN (static assets: images, CSS, JS)
  • CDN miss -> API Server -> PostgreSQL (products, orders, users)
  • No load balancer or cache needed yet -- the scale does not justify it

Key tradeoffs to discuss:

  • Keep it simple: one server + one DB is correct at this scale -- do not over-engineer
  • CDN dramatically reduces server load for product images and static files
  • Relational DB is right: structured schema, ACID transactions for orders
  • Vertical scaling (bigger server) before horizontal (multiple servers) is fine here
  • Next scaling step: add Redis cache when product page reads dominate

Learn the Concept

Practice Next

Reference SolutionClick to reveal

Why This Architecture Works

Simple and cost-effective - At ~10k daily visitors with 3x peak, a single API server can comfortably handle the load (~0.35 RPS average, ~1 RPS peak).

Key Components

  • DNS resolves the domain to the server IP. This is the entry point for all traffic.
  • CDN serves static assets (product images, CSS, JS bundles). This offloads ~80% of requests from the API server and keeps page loads under 500ms globally.
  • API Server handles dynamic requests - browsing the catalog, cart operations, and checkout. A single server is sufficient at this scale.
  • PostgreSQL stores the product catalog (~200 items), orders, and customer data. A relational database is ideal here because the data is structured and the scale is modest.

Why Not More?

At 10k daily visitors, adding a load balancer, cache layer, or multiple servers would be over-engineering. The budget is low (single small team), and a single server with a CDN achieves the 99.5% availability target. If the bakery grows (see Cake Shop 2), we can add caching and horizontal scaling later.