A social platform serves user profiles from edge caches worldwide. A user updates their profile and still sees the old one. How should this be handled?

What is happening

The write went to the origin. The read was served by an edge cache holding the previous value. This is normal and expected behaviour for a replicated cache, and it is unacceptable specifically for the user who made the change.

The distinction that resolves it

Read-your-writes matters for the author; eventual consistency is fine for everyone else. Nobody else notices that a profile photo takes thirty seconds to propagate. The author notices immediately and concludes the save failed — and then saves again, which is how a consistency annoyance becomes a duplicate-write problem.

The mechanisms, from cheapest to strongest

• Update the local view optimistically after a successful write. Solves the common case entirely with no infrastructure change, and is the first thing to do.
• A short-lived cookie or header marking the user as recently-written, causing the edge to bypass cache for that user's own resource for a bounded period. Targeted, cheap, and it does not affect anyone else's cache hit ratio.
• Active invalidation on write, purging the object at the edge. Effective, and purge propagation is itself not instantaneous and has a cost at high write rates.
• Short time-to-live on user-mutable objects, which is simple and trades cache efficiency across all readers to fix a problem only the author has.

What not to do

Do not disable edge caching for profiles to fix an author-only problem. That trades the cache hit ratio for every reader worldwide against a case affecting one user for a few seconds, and it is a large cost for a small correctness gain.

And do not rely on client clocks or client-side expiry to reason about freshness — the invalidation decision belongs to the server and the edge.