Module 95: Scaling

Why each option is right or wrong

• “Because averages are only accurate for small websites” (Incorrect): Averages can be calculated at any size; they just hide the slow tail.
• “Because percentiles make response times look smaller” (Incorrect): Percentiles usually look worse than averages, which is why they're honest.
• “Because p95 is easier for servers to calculate than averages” (Incorrect): Averages are simpler to calculate; p95 is used because it's more revealing.
• “Averages hide the slow experiences many users still have” is correct.

  If most requests take 100 ms but 1 in 20 takes 4 seconds, the average looks fine while thousands of users wait. The p95 is the time that 95% of requests beat; it shows how bad the slow end is, which is what frustrated users feel.

  • p99: the slowest 1%, often heavy users or big accounts.
  • Set targets: on percentiles, like p95 under 500 ms.

📖 Revise: Lesson 1: Measuring performance

Why each option is right or wrong

• “Compresses images and files on the way out so that every page loads faster” (Incorrect): Compression is done by servers or CDNs; balancing spreads requests.
• “Stores copies of the database across several servers so none is overloaded” (Incorrect): That's replication; a load balancer routes traffic.
• “Speeds up each server by lending it extra memory and CPU when it gets busy” (Incorrect): It shares the work between servers; it doesn't add memory.
• “Spreads requests across several servers and stops sending to unhealthy ones” is correct.

  A load balancer sits in front of your app servers and shares incoming requests between them. It checks each server's health regularly; if one stops responding, it sends traffic only to the healthy ones, so users aren't affected.

  • Also handles: HTTPS termination, in many setups.
  • Needs: stateless app servers, as in the next questions.

📖 Revise: Lesson 2: Load balancing

Why each option is right or wrong

• “Upgrading to a bigger server with more CPU and memory” (Incorrect): That's vertical scaling: one bigger machine.
• “Adding more memory to the database server only” (Incorrect): That's still vertical: a bigger single machine.
• “Moving the app to a faster hosting provider” (Incorrect): Changing provider doesn't by itself add servers.
• “Adding more servers” is correct.

  Horizontal scaling adds more machines that share the work, like opening more checkout counters. Vertical scaling makes one machine bigger, with more CPU and memory, like a faster cashier. Horizontal can keep growing and survives one server failing.

  • Vertical: simple, but has a ceiling and one point of failure.
  • Horizontal: needs a load balancer and stateless servers.

📖 Revise: Lesson 2: Load balancing

Why each option is right or wrong

• “Because databases can only accept connections from servers that are stateless” (Incorrect): Databases connect to any server; statelessness is about requests.
• “Because stateless servers use less electricity and memory than other servers” (Incorrect): Power use isn't the reason.
• “So each user is tied to the same server for every visit, keeping sessions simple” (Incorrect): That's sticky sessions, which statelessness avoids.
• “Any server can handle any request, so you can add or remove servers freely” is correct.

  If a server keeps session data or uploaded files in its own memory or disk, a user's next request must reach the same server. Keeping state in shared stores, such as the database, Redis or object storage, lets any server answer any request.

  • Store sessions: in Redis or the database.
  • Store uploads: in object storage, not the local disk.

📖 Revise: Lesson 2: Load balancing

Why each option is right or wrong

• “Installing and configuring Redis on the server” (Incorrect): Installation is quick; deciding when data is stale is harder.
• “Choosing a cache key name for each stored item” (Incorrect): Naming matters, but invalidation is the harder problem.
• “Deciding how much memory the cache server needs” (Incorrect): Sizing matters, but stale data is the harder problem.
• “Invalidation: knowing when cached data is out of date” is correct.

  Adding a cache is easy. Making sure it doesn't serve old prices, wrong stock or someone else's data is hard. You need expiry times and to clear entries when data changes, without clearing so often that the cache stops helping.

  • Strategies: short expiry times, clearing on update, versioned keys.
  • Don't cache: one user's private data under a shared key.

📖 Revise: Lesson 3: Caching

Why each option is right or wrong

• “Query the database every time with no cache, so the page is fully up to date” (Incorrect): It works, but wastes resources on identical queries.
• “Store it in each visitor's localStorage only, so the server isn't asked again” (Incorrect): New visitors still need it, and updates won't reach old copies.
• “Rebuild the whole database every night, so the page loads quickly by day” (Incorrect): That's slow and doesn't help read speed during the day.
• “Cache it (CDN or app cache) and clear it when the product changes” is correct.

  When reads hugely outnumber writes, serving a cached copy saves the database thousands of identical queries. Clearing the cache entry when the product is edited keeps the page accurate.

  • CDN: caches near the user, very fast.
  • Or: a short expiry time if instant updates aren't needed.

📖 Revise: Lesson 3: Caching

Why each option is right or wrong

• “Making writes faster on the main database during busy periods” (Incorrect): Writes still go to the main database; replicas help with reads.
• “Installing database security patches without any downtime” (Incorrect): Patching is a separate process.
• “Replacing backups, since a replica is a copy” (Incorrect): A replica copies mistakes too, like a deleted table; backups are still needed.
• “Spreading heavy read traffic off the main database” is correct.

  A read replica is a copy of the database that follows the main one. Reports, searches and listings can read from replicas, leaving the main database free for writes. Replicas can lag slightly, so read-after-write cases may need the main one.

  • Also useful: as a standby for failover.
  • Watch: replication lag.

📖 Revise: Lesson 4: Scaling the database

Why each option is right or wrong

• “Encrypting each table in the database with its own separate key, for safety” (Incorrect): That's encryption, not splitting data.
• “Deleting old rows on a schedule to keep the main database small and quick” (Incorrect): That's archiving or retention.
• “Copying the whole database to a second server that can take over if needed” (Incorrect): That's replication; each copy holds all the data.
• “Splitting data across several databases by a key, like region or customer” is correct.

  When one database can't hold or handle all the data, sharding splits rows across several databases, each holding a part, for example customers A–M on one and N–Z on another. It adds a lot of complexity, so it's usually a late step.

  • Try first: indexes, caching, replicas, a bigger server.
  • Hard parts: queries across shards, rebalancing.

📖 Revise: Lesson 4: Scaling the database

Why each option is right or wrong

• “Make the user wait 40 seconds with a loading spinner” (Incorrect): Long requests tie up the server and often time out.
• “Generate it in the browser with JavaScript instead” (Incorrect): Heavy reports often need server data and power; a background job is more reliable.
• “Increase the server's timeout to two minutes” (Incorrect): That keeps resources tied up and doesn't help the user.
• “Queue a background job and notify the user when it's ready” is correct.

  Holding a web request open for 40 seconds ties up the server and often hits timeouts. Instead, the request adds a job to a queue and returns immediately. A worker builds the PDF, then the user gets a notification or download link.

  • Show: "Your report is being prepared."
  • Module 94: covers queues and workers.

📖 Revise: Lesson 5: Asynchronous work and scaling costs

Why each option is right or wrong

• “How many developers are available to work on it” (Incorrect): Team size matters later; first find the actual cause.
• “Which cloud provider offers the cheapest large servers” (Incorrect): Price comparison comes after you know you need more servers.
• “Whether the users' own internet connections are fast enough” (Incorrect): Users' connections matter a little, but slow server-side work is the usual cause and the one you can fix.
• “Where time is actually spent: slow queries, missing indexes, N+1 calls” is correct.

  Most slow apps are slow because of a few fixable problems, such as a query without an index or a loop making 100 database calls. Measuring first, with logs, query plans or profiling, often gives a big speed-up at no extra cost.

  • Tools: EXPLAIN in SQL, APM tracing.
  • Then: scale if it's still needed.

📖 Revise: Lesson 5: Asynchronous work and scaling costs