Both, before you answer
Write-through updates your cache and your database as one operation, and does not tell the client it worked until both have it.
Get one guarantee out of that: your cache is never behind your database, so any read following a write sees the new value. If your product promises people see their own changes immediately, this delivers it with no extra machinery.
Pay for it on every single write. Instead of one trip to the database you make two, and the slower one sets your latency.
Expect the database write to dominate in practice, so this costs maybe 10 to 30 percent more latency rather than double. It also doubles the number of things that can fail halfway through.
Answer the awkward case before it happens: the database write succeeds and the cache write fails, or the reverse. The usual answer is to delete the key on any failure and let the next read repopulate it, which converts an inconsistency into a harmless miss.
What it pollutes
Notice the pollution write-through causes. Every key you write lands in memory, including bulk imports, background jobs, and rows written once and read never.
On a workload with many cold writes you evict genuinely hot data to store speculative entries, and that is the specific problem the next lesson exists to fix.
Spend it where data gets read straight after being written. Shopping carts, settings, session state, document edits. The write and the next read are seconds apart, and a stale read is a visible bug.
Pair it with read-through when a managed product hands you both, which is why the two names always travel together in vendor documentation.
Worked example
Aditi builds the settings service for a fintech app. Users toggle a card freeze, and the mobile app immediately re-fetches the card state to render the confirmation screen. With cache-aside plus a delete-on-write, a race occasionally repopulated the old value, and roughly one user in a thousand saw the freeze toggle flip visually back off after freezing. For a feature whose entire point is reassurance, that read at 0.1 percent was unacceptable. She moved card state to write-through: the API writes Postgres, a relational database, then writes the new state into Redis, an in-memory store, with a TTL, meaning a lifetime, of an hour before returning 200. Write latency went from 9 ms to 11 ms, which nobody noticed. The flicker reports stopped entirely, and the confirmation screen now always reflects what the user just did.