Module
Module 4 of 6Lesson 2 of 3~17 min

Handling the load, finding the bottleneck, deciding on a cache

When a page slows down at peak usage, the reflex to add servers or a cache gets expensive if it aims at the wrong target. The lesson shows how a PM estimates load from their own product numbers, gets the bottleneck located before any fix is chosen, and takes part in the caching decision.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to estimate the load of a peak from a few product figures, get the bottleneck of a journey identified before any solution, tell vertical and horizontal scaling apart, and decide with the team whether a cache is relevant and with what freshness.

Topics covered

  • scalability
  • performance bottleneck
  • horizontal scaling
  • caching
  • load estimation

Where it fits

Data, load and dependencies

Where does the data live, what will give way first under load, and what happens when a vendor goes down?

Lessons in this module

  1. Where does the data live, and when is it up to date?
  2. Handling the load, finding the bottleneck, deciding on a cache (this lesson)
  3. Third-party services, composite availability, build or buy

What you will learn in the course

This lesson is part of the course Read and challenge a technical architecture

  • Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
  • Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
  • Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
  • Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
  • Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
  • Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
  • Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.

Related courses