Module 91: Introduction to System Design

Why each option is right or wrong

• “Non-functional: a quality the system must have” (Incorrect): Non-functional means qualities like speed or uptime; booking is an action, so it's functional.
• “A deployment detail about where the system runs” (Incorrect): Deployment is about servers and hosting; this describes what users can do.
• “A user interface design for the booking page” (Incorrect): It says what must be possible, not how the screen should look.
• “Functional: something the system must do” is correct.

  Functional requirements describe behaviour: what the system lets people do, such as book, cancel or pay. This one names an action a customer can take, so it's functional. Qualities like speed, security and uptime are non-functional.

  • Tip: functional requirements often start "Users can...".
  • Next step: add details, such as who can book and what happens next.

📖 Revise: Lesson 1: Functional requirements

Why each option is right or wrong

• “Functional, because it describes what the pages do” (Incorrect): Loading a page is assumed; the requirement sets how fast, which is a quality.
• “A user story about how a customer books a session” (Incorrect): A user story describes a goal like booking; this sets a speed target.
• “A database schema rule for storing page data” (Incorrect): Schemas describe data structure; this is a performance target.
• “Non-functional (performance)” is correct.

  This sets a quality target, how fast, rather than a feature. It's measurable: you can test load times and check whether 95% of them are under 2 seconds.

  • Other non-functional examples: 99.9% uptime, data encrypted at rest.
  • Lesson 3 of this module: links these to design choices.

📖 Revise: Lesson 2: Non-functional requirements

Why each option is right or wrong

• “Because words aren't allowed in a requirements document” (Incorrect): Words are fine; vague words just can't be checked.
• “Because writing numbers makes the system run faster” (Incorrect): Numbers set a target; they don't change speed on their own.
• “Because numbers look more professional to clients” (Incorrect): Looks aren't the point; being measurable is.
• “Numbers can be measured and tested” is correct.

  "Fast" means different things to different people, so nobody can say whether it's met. "95% of pages under 2 seconds" can be measured, tested in CI and checked in monitoring, and everyone agrees on what success looks like.

  • Security too: "passwords hashed with bcrypt, MFA for admins".
  • Helps design: numbers show which problems matter.

📖 Revise: Lesson 2: Non-functional requirements

Why each option is right or wrong

• “The server's CPU and memory use over time” (Incorrect): That's a monitoring graph, not a C4 diagram.
• “The database tables and the columns in each” (Incorrect): That's a data model or schema diagram.
• “Every class in the code and how they connect” (Incorrect): That's the most detailed Code level, rarely drawn by hand.
• “The system as one box, with its users and the outside systems it talks to” is correct.

  The Context diagram is the big-picture view. Your whole system is a single box in the middle, surrounded by the people who use it and the external systems it connects to, such as a payment provider or email service. It's simple enough for non-technical people.

  • C4 levels: Context, Containers, Components, Code.
  • Start here: before zooming in.

📖 Revise: Lesson 3: Components and C4 diagrams

Why each option is right or wrong

• “Only the Docker containers the system is packaged in” (Incorrect): "Container" in C4 means any running part, Docker or not.
• “The code inside each function, line by line” (Incorrect): That's far more detail than a Container diagram shows.
• “The users and outside systems around one system box” (Incorrect): That's the Context diagram, one level higher.
• “The separately running parts, like web app, API and database, and how they talk” is correct.

  Zooming into the system box, the Container diagram shows each separately deployed or running part: the web frontend, the API, the database, a background worker. Arrows show how they communicate, such as HTTPS or SQL.

  • "Container": any running unit, not only Docker.
  • Useful for: discussing deployment and security boundaries.

📖 Revise: Lesson 3: Components and C4 diagrams

Why each option is right or wrong

• “Writing tests makes the code run slower in production” (Incorrect): Tests run before release; they don't slow production code.
• “Adding a cache makes reads faster and has no downsides” (Incorrect): Caches do have downsides, like stale data and extra complexity.
• “Using HTTPS makes the site's data visible to the public” (Incorrect): HTTPS encrypts traffic; it protects data rather than exposing it.
• “Adding a cache makes reads faster but data can be slightly stale” is correct.

  A cache keeps a copy of data so it can be served quickly, but the copy can lag behind the real data until it's refreshed or cleared. That's a genuine trade-off between speed and freshness, which you manage with expiry times and invalidation.

  • Other real trade-offs: microservices give independence but add complexity.
  • Record: trade-offs in a decision record.

📖 Revise: Lesson 4: Trade-offs

Why each option is right or wrong

• “Twelve microservices connected by a message bus” (Incorrect): That adds big operational costs that 200 users don't need.
• “A separate server for each user, for isolation” (Incorrect): That's very costly and complicated for no real benefit.
• “A blockchain, so bookings can't be changed” (Incorrect): Bookings need to change, and a normal database does this simply.
• “One web app, one API, one managed database” is correct.

  200 users is a small load that a single app and database handle easily. A simple design is quicker to build, cheaper to run and easier to debug. You can add caching, replicas or split services later if real numbers show you need them.

  • Managed database: the provider handles backups and updates.
  • Grow later: based on measurements, not guesses.

📖 Revise: Lesson 5: Designing a small system

Why each option is right or wrong

• “Because design interviews always ask for them” (Incorrect): Interviews ask because the numbers matter for real design decisions.
• “To make the design document look more detailed” (Incorrect): The point is making better choices, not a longer document.
• “They don't matter, since any design can grow later” (Incorrect): Some choices are costly to change; numbers help you choose well early.
• “They tell you which problems you actually have” is correct.

  If you expect 10 requests a second, one server is plenty; at 10,000 a second you need caching and scaling. Rough numbers stop you over-building for problems you don't have, or under-building for ones you do.

  • Example: 200 users × 20 requests a day is tiny.
  • Revisit: when real usage data arrives.

📖 Revise: Lesson 5: Designing a small system

Why each option is right or wrong

• “The two app servers, since there are two to fail” (Incorrect): Two servers back each other up; one failing doesn't stop the system.
• “The load balancer's health checks” (Incorrect): Health checks help route around failures; they're not the weak spot here.
• “The users' browsers, which may lose connection” (Incorrect): One browser failing affects one user, not the system.
• “The database” is correct.

  A single point of failure is one part whose failure stops the whole system. With two app servers, one can fail and the other carries on. With one database and no replica, if it goes down, nothing can read or save bookings.

  • Fix: a standby replica with automatic failover.
  • Also: tested backups.

📖 Revise: Lesson 5: Designing a small system

Why each option is right or wrong

• “Only the designer, who understands the whole system” (Incorrect): One person can miss what users and the business need.
• “Only the developers, who will build it” (Incorrect): Developers know the technology best; users and the business know what they need.
• “Nobody, since requirements will emerge during building” (Incorrect): Some details emerge, but the core needs should be agreed early.
• “The people who will use and pay for the system, and the builders” is correct.

  Users know what they need, the people paying decide priorities and budget, and builders know what's practical. Agreeing together early avoids building the wrong thing, which is the most expensive mistake.

  • Write them down: and share them.
  • Expect changes: but agree how changes are made.

📖 Revise: Lesson 1: Functional requirements