---
title: '5 Ways to Scale Reads: Most Engineers Know Only 2'
source: 'https://youtube.com/watch?v=ljd4WmSHUoY'
video_id: 'ljd4WmSHUoY'
date: 2026-08-04
duration_sec: 60
---

# 5 Ways to Scale Reads: Most Engineers Know Only 2

> Source: [5 Ways to Scale Reads: Most Engineers Know Only 2](https://youtube.com/watch?v=ljd4WmSHUoY)

## Summary

The video discusses strategies for scaling database reads, highlighting that most engineers are familiar with only two methods, but there are five effective levers. It covers CDN caching, materialized views, and application-level caching, in addition to the commonly known read replicas, and provides a playbook for when to use each approach.

### Key Points

- **Read Replicas** [00:01] — The first lever for scaling reads is read replicas, which are commonly known. They help distribute read traffic but are not the only option.
- **CDN Caching** [00:01] — CDN caching serves cacheable responses from edge servers, reducing origin load times by 90% or more. Best for geographically distributed users.
- **Materialized Views** [00:14] — Materialized views precompute expensive queries and store results as a table. Useful for slow queries with underlying data that changes infrequently, such as rankings, leaderboards, or aggregate counts.
- **Application-Level Caching** [00:27] — Application-level caching stores results in the app server's memory. It is fast but dies on restarts and does not share across instances.
- **Scaling Playbook** [00:43] — The recommended playbook: start with caching, add read replicas when the database still struggles, push to the edge when latency matters, and precompute expensive queries.

### Conclusion

The video provides a concise, actionable framework for scaling database reads, emphasizing a layered approach that combines caching, replicas, edge delivery, and precomputation to handle increasing read loads effectively.

## Transcript

read replicas, but there are three more levers to scaling reads. The first is CDN caching. You can serve cacheable responses from edge servers that are You'd want to use this when your users are geographically distributed and you
want to cut origin load times by 90% or more. Next are materialized views. You can precompute expensive queries and store those results as a table. You'll use this whenever the queries are really slow, but the underlying data changes
rankings, leaderboards, or aggregate counts. Last is application level caching. You can store results directly in your app server's memory. This gives course it dies on restarts and it doesn't share across instances. Combined
the playbook. Start with caching, add read replicas when your database is still struggling, push to the edge when latency matters, and precompute those queries that are too expensive to run live. Learn more at hellointerview.com.