Cache-aside vs write-through vs write-back

The decision

A cache is a small, fast store that keeps copies of data you read often. When data changes, you must decide who writes the cache, and when. With cache-aside, the app writes the database, then deletes the cache entry. With write-through, every write goes to the database and the cache, and the app waits for both. With write-back, the app writes only the cache, and the cache saves to the database a little later.

Choose cache-aside when

• Reads are much more common than writes. Assumption: 100 reads for each write.
• Only some items are ever read, so only those should enter the cache.
• A stale value for a short time is fine. A time to live (TTL) ends any mistake: the entry expires after a set time.

Choose write-through when

• Most written items are read soon after. A new order is read by its owner right away.
• The first read after a write must be fast, so you cannot accept the extra miss that cache-aside causes.
• Writes are below the database limit, because each write waits for both stores.

Choose write-back when

• Writes per second are above what the database can take, and many writes hit the same key. A page-view counter is an example.
• You accept losing the last few seconds of changes if the cache fails.
• Nobody reads the database directly, because it lags behind the cache.

The numbers that change the answer

Assumptions: a database write takes 10 ms. A cache write takes 1 ms. The database takes 1,000 writes per second.

Worked example 1 (Assumption: a page-view counter). It goes up 2,000 times per second. Cache-aside or write-through sends 2,000 writes per second to a database that takes 1,000. That is 2,000 / 1,000 = 200%, so the database fails. With write-back and a flush every 1 second, the counter is saved once per second: 1 write per second, which is 0.1% of the limit. If the cache fails, you lose up to 1 second x 2,000 = 2,000 views. For a page-view count, that is acceptable.

Worked example 2 (Assumption: write-through memory). The app writes 500 new items per second, 1 KB each, and the TTL is 1 hour. Memory = 500 KB per second x 3,600 seconds = 1,800,000 KB = 1.8 GB. If only 10% of items are ever read, 90% of that memory is waste: 1.62 GB. Cache-aside would hold only the read items, about 0.18 GB.

Assumption: write-through pays off if more than half of the written items are read within the TTL. Measure your own share.

What breaks with each choice

• Cache-aside: if you delete the cache entry before the database write, a reader can refill the cache with the old value. Always write the database first. A crash between the two steps leaves an old value until the TTL ends, so keep a TTL. A rare race remains: a slow reader that loaded the old value can store it after your delete, and the TTL limits the harm. After each write there is one extra miss.
• Write-through: writes are slower, because of two steps. If the cache write fails, the cache is old. If two writers race, the older value can win in the cache. Make writes to one key happen in order.
• Write-back: the cache can fail before it saves, and the changes are gone. Readers of the database see old data. Fix: flush often, keep a log of pending changes, and use it only for data you can lose.

What it costs

• Cache-aside is the cheapest to build: two small pieces of code.
• Write-through needs every write path to use the cache, and more memory (1.8 GB in example 2).
• Write-back needs a flush job, retries and a test that kills the cache. Assumption: 1 to 2 engineer-weeks.
• Changing later: cache-aside to write-through is a small code change. Moving to write-back is a design change, because the cache becomes the first home of the data.

How each level answers

SDE-1: Cache-aside reads the cache first and fills it on a miss. On a write it updates the database and deletes the entry. Write-through writes both. Write-back saves later.

SDE-2: I use cache-aside for product pages, because they are read far more than written. I use write-through when users must see their own writes at once. I avoid write-back for orders, because a cache failure would lose them.

Senior: A counter at 2,000 writes per second is 200% of a 1,000 per second database, so only write-back fits. With a 1 second flush, I lose at most 2,000 increments. For a page-view count I accept that. For payments I do not. The failure is a cache crash, so I keep a log of pending changes.

Staff: The choice is a statement about what the business may lose. I ask the product owner how many seconds of data they accept losing, and write that number down. The team that owns the data owns the flush job. I roll out by key type, cache-aside first. I measure database writes per second, hit rate and lost increments in a monthly kill test.

Say it in the interview

"I default to cache-aside: write the database first, then delete the cache entry, with a TTL as a safety net. A counter at 2,000 writes per second is too much for a database that takes 1,000, so I use write-back with a 1 second flush and accept losing up to 2,000 increments. I never use write-back for orders or payments."

Common mistakes

• Deleting the cache entry before writing the database. It is wrong because a reader can store the old value in between, and it stays until the TTL ends.
• Updating the cache instead of deleting it when two writers race. The older write can arrive last and stay.
• Using write-back for important data. It is wrong because the database never had the lost changes, so no repair job can bring them back.

Sources

• Microsoft Azure Architecture Center, Cache-Aside pattern (write the data store first, then invalidate): https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside (opens in a new tab) (checked 26 Oct 2026).
• All timings, rates, sizes and the 50% line are assumptions made for teaching. The arithmetic is calculated from them.