Module
Module 4 of 6Lesson 1 of 3~16 min

Where does the data live, and when is it up to date?

A number that differs from one screen to the next is enough to shake customer trust, and knowing where data lives prevents that kind of incident. This lesson helps a PM identify which store is authoritative for a feature, understand what replicas and synced copies cost, and state the freshness each screen can tolerate.

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

Lesson objective

By the end of this lesson, you will be able to name the source of truth for each piece of data in a feature, explain what a transaction guarantees and what copies cost (read replicas, caches, synchronized data), and specify the acceptable freshness and the behavior when copies differ.

Topics covered

  • source of truth
  • database transaction
  • read replica
  • data consistency
  • data freshness

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? (this lesson)
  2. Handling the load, finding the bottleneck, deciding on a cache
  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