Designing a small system

📘What it really is

A repeatable design process, applied to the booking platform:

1. Clarify the problem, users and scale: for example, 500 tutors, 20,000 students, peak evenings 7 to 10 pm, mostly in India.
2. Requirements: functional (Lesson 1) and non-functional (Lesson 2), prioritised.
3. Estimate: rough numbers guide choices:
4. bookings: say 3,000 a day, peaking at about 5 a minute: easily handled by one database;
5. searches: perhaps 50 per booking → 150,000 a day, around 10 a second at peak: a single API server with caching manages this;
6. storage: tiny for bookings; profile photos go to object storage (Module 68).
7. Data model: the main entities and relationships: tutors, students, subjects, availability_rules, slots, bookings, payments, notifications, with constraints (a unique booking per slot) (Level 5).
8. API design: the key endpoints (GET /v1/tutors?subject=, GET /v1/tutors/:id/slots?week=, POST /v1/bookings, POST /v1/payments/webhook) (Module 46).
9. Architecture: the C4 diagrams (Lesson 3): a React app, a Node.js API, PostgreSQL, a background worker for reminders and payment reconciliation, a payment gateway, an email/SMS provider.
10. Key flows: step-by-step sequence of booking and payment, including failures (payment times out; the webhook arrives late; the student closes the page).
11. Cross-cutting concerns: authentication and roles, time zones, idempotency of payments, logging and monitoring, backups, privacy (Levels 4 to 7).
12. Trade-offs and risks: your ADRs; what would change at 10 or 100 times the scale.
13. Review: walk someone through it; invite challenges.