Question 1

What is caching, and why is it needed? Use the learning-platform example.

Accepted Answer

Caching stores frequently accessed data in a high-speed temporary layer (memory) so the application does not query the database for the same information again and again.

A user enrolled in 6 courses × 4 sections needs 24 database requests to load the dashboard. Without a cache every refresh repeats those 24 queries: database response time climbs, server resources burn, the user waits.

Question 2

Describe the request flow with a cache in place and the benefits.

Accepted Answer

1. User requests course information.
2. Application checks the cache.
3. Not found: fetch from the database.
4. Store the result in the cache.
5. Subsequent requests are served from the cache.

Benefits: faster responses, less database traffic, lower server load, better scalability and user experience. The cache complements the database; it never replaces it.

Question 3

Cache hit vs cache miss.

Accepted Answer

Hit: the data is in the cache and is returned immediately; no database query.

Request → Cache → Data found → Response

Miss: the data is not in the cache; the database is queried, the result is returned and usually stored in the cache for next time.

Request → Cache (miss) → Database → Response → Store in cache

Question 4

What is TTL?

Accepted Answer

Time To Live: how long a cached item stays valid. When the TTL expires the entry becomes invalid, is removed automatically, and a fresh copy is fetched from the database on the next request. Example: course data with TTL = 30 minutes.

Question 5

How is data stored inside a cache?

Accepted Answer

As key-value pairs plus metadata.

- Key: unique identifier, e.g. user:101, course:501, product:2001.
- Value: the data, e.g. { "courseId": 501, "courseName": "System Design", "sections": 4 }.
- Metadata: TTL, creation time, last access time, expiration timestamp.

Question 6

What is cache eviction in the context of expiry?

Accepted Answer

When an entry reaches its expiration time it becomes invalid, the cache removes it automatically, memory is freed for new entries, and fresh data is loaded from the database when needed. (Capacity-driven eviction policies are the next page.)

Question 7

Why not cache all the data?

Accepted Answer

- Limited memory: Cache memory is much smaller and more expensive than database storage
- Only hot data pays off: Frequently requested data gives the performance benefit; cold data just occupies space
- Consistency: Cached data must be refreshed regularly or it goes stale

Question 8

What does a caching strategy decide, and what is it balancing?

Accepted Answer

How data is stored, retrieved and synchronized between the cache and the database. The choice balances performance, consistency, scalability and reliability.

Question 9

Read-through cache: flow, key points, example.

Accepted Answer

- Read (hit): Request → Cache → Response
- Read (miss): Request → Cache (miss) → Database → Store in cache → Response
- Write: Request → Database directly (cache not updated)

The cache is populated only on a miss, so the first read of anything always misses. Best for read-heavy workloads where written data is not immediately read. Example: product listings are cached; order placements go straight to the database.

Question 10

Write-through cache: flow, key points, example.

Accepted Answer

- Write: Request → Cache (updated) → Database (updated, synchronously)
- Read: Request → Cache → Response

The cache always holds the latest data, so consistency is strong and reads are very fast. Write latency is slightly higher because both stores update on every write. Example: stock prices that must always reflect the latest value.

Question 11

Write-around cache: flow, key points, example.

Accepted Answer

- Write: Request → Database directly (bypasses cache)
- Read (hit): Request → Cache → Response
- Read (miss): Request → Cache (miss) → Database → Store in cache → Response

Keeps the cache from being polluted with data that may never be read, so only hot data occupies it. Risk: stale entries if cached data is not invalidated after a database update. Example: logging systems that write huge volumes but read only a small slice later.

Question 12

Write-back (write-behind) cache: flow, key points, example.

Accepted Answer

- Write: Request → Cache (immediately) → Database (asynchronously, later)
- Read (hit): Request → Cache → Response
- Read (miss): Request → Cache (miss) → Database → Store in cache → Response

Prioritizes performance over immediate consistency: very low write latency, ideal for high write traffic. Risk: data loss if the cache fails before the asynchronous database update completes. Example: food-delivery order-tracking status that changes every few seconds.

Question 13

Compare the four strategies and say how you would pick one.

Accepted Answer

- Read-through: Writes go to - Database only. Consistency - Eventual. Write latency - Normal. Pick when - Read-heavy, writes rarely read back.
- Write-through: Writes go to - Cache then database (sync). Consistency - Strong. Write latency - Slightly higher. Pick when - Reads must always see the latest write.
- Write-around: Writes go to - Database only. Consistency - Risk of stale. Write latency - Normal. Pick when - Write-heavy data seldom read soon after.
- Write-back: Writes go to - Cache, database later (async). Consistency - Eventual, loss risk. Write latency - Lowest. Pick when - Very high write rate, some loss tolerable.

SAY THIS:
Ask two questions: is the workload read-heavy or write-heavy, and can a read tolerate stale data? Those two answers pick the strategy.

Question 14

What is a cache eviction policy, and what does a good one achieve?

Accepted Answer

Cache memory is limited; when it is full, something must go. The policy decides which entries to remove. A good policy maximizes the hit rate, improves performance, uses memory well and keeps the most valuable data resident.

Question 15

LRU (Least Recently Used): rule, worked example, use cases.

Accepted Answer

Remove the item that has gone the longest without being accessed; if it was not used recently it probably will not be needed soon.

Access: A → B → C → D, then B → C
Recency: D (least recent) → A → B → C (most recent)
Cache full → evict D

Example: after a new phone launches, older models are searched less and their product data is evicted first. Use cases: web apps, browser caching, database query caching, CDNs. The most widely used policy.

Question 16

MRU (Most Recently Used): rule, example, use cases.

Accepted Answer

Remove the item accessed most recently; the assumption is that something just used is unlikely to be needed again immediately. Access A → B → C → D, evict D. Example: a discount coupon just applied at checkout will not be used again right away, so its cached data can go. Use cases: batch processing, sequential access workloads, some analytical apps.

Question 17

LFU (Least Frequently Used): rule, example, use cases.

Accepted Answer

Remove the item with the fewest accesses; low access count means low value.

- Gadgets: 500
- Clothes: 300
- Books: 120
- Plants: 25 → evicted first

Use cases: recommendation systems, search engines, streaming platforms, any workload with consistently popular items.

Question 18

FIFO (First In First Out): rule and its weakness.

Accepted Answer

Remove whatever entered the cache first, regardless of how often or recently it was used; a queue. Insert User1 → User2 → User3 → User4; on the next insert User1 is evicted even if it is still hot. Simple; use where simplicity beats optimization, or in queue-based processing.

Question 19

LIFO (Last In First Out): rule and use cases.

Accepted Answer

Remove the most recently inserted entry first; a stack. Insert Course1 → Course2 → Course3 → Course4; when full, Course4 goes. Use cases: stack-based systems, specialized processing, temporary data structures.

Question 20

Compare the five eviction policies.

Accepted Answer

- LRU: Evicts - Least recently accessed. Structure - Recency order. Good for - General purpose; most common.
- MRU: Evicts - Most recently accessed. Structure - Recency order. Good for - Sequential or one-shot access.
- LFU: Evicts - Lowest access count. Structure - Frequency counters. Good for - Stable popularity (recommendations, search).
- FIFO: Evicts - Oldest inserted. Structure - Queue. Good for - Simplicity.
- LIFO: Evicts - Newest inserted. Structure - Stack. Good for - Stack-like workloads.

The right policy depends on access patterns, performance needs, memory constraints and the nature of the data.