Scaling Checkpoint

Design GreenMart's Scaling Plan

Playground Checkpoint

Design and build a real schema — no auto-grading, just a real attempt.

20–24 min

The Challenge

GreenMart is opening its fourth city: Chennai. Mike wants the company-wide reporting view to include it from day one — without touching a single row of Mumbai's, Delhi's, or Bangalore's existing data.

Open the Playground and do it yourself: give Chennai its own shard, then extend the shared view so it's part of the company-wide picture, the same way every other city already is.

What Your Schema Needs

  • Create a new Orders_Chennai table, with the exact same shape (columns and types) as the other three city tables.
  • Insert at least two sample orders into Orders_Chennai.
  • Rebuild the AllCitiesOrders view so it includes Chennai alongside the other three cities — remember SQLite has no CREATE OR REPLACE VIEW, so the existing view has to be dropped first.
  • Confirm the total order count across AllCitiesOrders increased by exactly the number of Chennai orders you inserted, and that each of the other three cities' individual counts is completely unchanged.
Stuck? A Few Hints
  • Orders_Chennai needs to match the other city tables' schema exactly (OrderID, CustomerID, OrderDate, Total) — the view's UNION ALL only works if every branch returns the same columns.
  • SQLite has no CREATE OR REPLACE VIEW — you have to DROP VIEW AllCitiesOrders first, then CREATE VIEW it again with the new UNION ALL branch included.
  • Group by City and COUNT(*) on the rebuilt view to confirm Mumbai, Delhi, and Bangalore's counts are exactly what they were before — the whole point of sharding is that adding a new shard shouldn't disturb any existing one.

Ready to Build It?

Opens the Playground, right in your browser — nothing to install.

Open Playground

Before You Move On

Every idea from this Act lands here — a new shard added the same way every other one was built, a view rebuilt through DROP-and-CREATE because SQLite offers no shortcut around it, and confirmation that nothing already running was disturbed in the process. GreenMart can keep opening cities from here, on a real, repeatable plan instead of a one-off fix. Growth like this doesn't go unnoticed, either — Mike mentioned, almost in passing, that a smaller rival across town has quietly been asking about being bought out. What's left is stepping back: how does GreenMart's own database compare to the systems that inspired it all along?

Next