5 Ways to Scale Reads (Most Engineers Know 2)
43sThe title promises a knowledge gap, and the content quickly lists actionable scaling techniques, making it highly shareable for engineers.
▶ Play ClipAI 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.
Chapters
[00:01]
Read Replicas
The first lever for scaling reads is read replicas, which are commonly known. They help distribute read traffic but are not the only option.
[00:01]
CDN Caching
CDN caching serves cacheable responses from edge servers, reducing origin load times by 90% or more. Best for geographically distributed users.
[00:14]
Materialized Views
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.
[00:27]
Application-Level Caching
Application-level caching stores results in the app server's memory. It is fast but dies on restarts and does not share across instances.
[00:43]
Scaling Playbook
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.
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.
Mentioned in this Video
Study Flashcards (5)
What are the five ways to scale reads mentioned in the video?
easy
Click to reveal answer
What are the five ways to scale reads mentioned in the video?
easy
Click to reveal answer
Read replicas, CDN caching, materialized views, application-level caching, and precomputing expensive queries.
00:01
When should you use CDN caching?
medium
Click to reveal answer
When should you use CDN caching?
medium
Click to reveal answer
When users are geographically distributed and you want to cut origin load times by 90% or more.
00:01
What is the purpose of materialized views?
medium
Click to reveal answer
What is the purpose of materialized views?
medium
Click to reveal answer
To precompute expensive queries and store results as a table, useful for slow queries with infrequently changing data like rankings or leaderboards.
00:14
What are the limitations of application-level caching?
easy
Click to reveal answer
What are the limitations of application-level caching?
easy
Click to reveal answer
It dies on restarts and does not share across instances.
00:27
What is the recommended playbook for scaling reads?
medium
Click to reveal answer
What is the recommended playbook for scaling reads?
medium
Click to reveal answer
Start with caching, add read replicas when the database struggles, push to the edge when latency matters, and precompute expensive queries.
00:43
💡 Key Takeaways
📊
CDN caching reduces origin load by 90%
Provides a concrete performance metric that quantifies the benefit of edge caching.
00:01
🔧
Materialized views for expensive queries
Introduces a technique for precomputing slow queries, a key optimization strategy.
00:14
⚖️
Layered scaling playbook
Offers a practical, ordered approach to scaling reads, making the advice actionable.
00:43Full Transcript
[00:01] 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
[00:14] 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
[00:27] 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
[00:43] 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.
