Why should you care?

ShopNest cannot “just add servers” blindly. You need a clear picture of where traffic goes and what fails first on Big Billion Days.

See it live — copy this example

Sketch the architecture on paper. These lessons focus on concepts and trade-offs.

# ShopNest — first sketch
[Mobile/Web] → [API] → [Orders DB]
                ↘ [Catalog Cache]

Ask: Who calls whom? What must never lose data?

Run Example »

This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.

What happened?

• The sketch shows three paths: UI to API, API to the database of record, and a read path via cache.
• Every later lesson adds boxes without losing this habit of drawing the flow.

Practice next

1. Draw ShopNest with client, API, and one database.
2. Mark which arrow is a read and which is a write.
3. Circle the component that would hurt sales most if it dies.
4. Add a payment box and one new arrow.
5. Remove the cache and say what gets slower.

Remember

System design = components + flows + trade-offs. Start with a tiny sketch, then scale it. Always mark reads vs writes.

ShopNest kickoff whiteboard

Engineers sketch client → API → DB before coding checkout.

Outcome: Everyone shares one mental model of the order path.