A player finishes a ranked match and lands a new personal best. You write the result to the database, and now a few other things should happen. The leaderboard needs recomputing. The cached top ten is stale. A couple of friends should probably get a “you’ve been overtaken” notification. None of that has to finish before you tell the player “result saved”, but all of it has to happen eventually.
The obvious move is to keep that work out of the request. Drop it on a queue, let a worker pick it up, and respond right away. That’s event-driven thinking, and it’s the right instinct.
But “event” is one of the most overloaded words we use. Sometimes it means “do this thing, just not right now”, a note you leave for yourself. Sometimes it means “this happened, in case anyone cares”, an announcement to the world. On the wire they look the same: a message on a queue. In intent they’re opposites, and mixing them up is where a lot of event-driven designs quietly go wrong.
This post is about both jobs: offloading work inside your own app, and broadcasting facts to other services. Mostly it’s about where the line between them sits.
(more…)