Event-driven architecture definition
Event-driven architecture is a software architecture style in which services communicate by producing and reacting to events, where an event is a record that something happened, such as a state change or an update.
Event-driven architecture is a way of building systems where services talk to each other by announcing that something happened, rather than by calling each other directly and waiting for an answer. In Sanity, publishing a document emits a document event that the Content Lake routes to any Function whose Blueprint subscribes to it, so a sync to a search index or a commerce platform runs as a reaction to the change instead of on a polling schedule.
An event-driven architecture has three parts: producers, a router or channel, and consumers. A producer emits an event when something happens in its part of the system, and it does not know or care who will read it. A router (Amazon calls it an event router, Microsoft calls it an event channel or broker) receives the event and delivers it to whoever is interested, sometimes filtering it, fanning it out to several destinations, or storing it. A consumer reacts, and several consumers can react to the same event in parallel, each for a different purpose.
AWS uses a shopping cart as the canonical example: an item being placed in a cart is a change in state, and that change is the event. Events can carry the state itself (the item purchased, its price, and a delivery address) or identifiers, such as a bare notification that an order shipped.
That difference is a real design decision. Microsoft's Azure Architecture Center frames it as two payload strategies: put all required attributes in the payload, and consumers never have to call back to the source system, at the cost of larger payloads, more bandwidth, and harder contract versioning as the event shape changes. Put only keys in the payload, and consumers fetch the rest from the source, which keeps one system of record and better consistency, but adds queries against that source.
Publish-subscribe and event streaming are two delivery models inside event-driven architecture, and they differ on whether past events can be read again. In publish-subscribe, the infrastructure tracks who has subscribed and pushes each published event to each subscriber. The event is not kept in a durable log, so a consumer that subscribes tomorrow will never see what happened today. In event streaming, events are written to a log, ordered within a partition and durable, and clients read from any position and advance through the log themselves.
That second model makes replay possible. Microsoft ties replayability to three concrete situations in its event-driven architecture style guide: recovery scenarios, late-arriving consumers, and reprocessing after a bug fix has been deployed.
Neither model is the same as a work queue. Microsoft draws the line explicitly against the Competing Consumers pattern, where consumers pull messages from a queue and each message is processed exactly once, absent errors. In the publish-subscribe form of event-driven architecture, every consumer sees all of the events, because the point is notification, not work distribution.
No. Event-driven architecture is how services communicate with each other, not how a single service stores its state. Event sourcing is a storage pattern where a single service records state changes as a sequence of events. A system can do either one without the other, and conflating them is the most common confusion around the term.
Martin Fowler untangled this in "What do you mean by 'Event-Driven'?", which opens by observing that when people talk about events they mean quite different things. He names four patterns. Event notification sends a message that something changed and does not much care about the response. Event-carried state transfer puts the changed data in the event so recipients keep their own copy and never call back, which buys resilience and lower latency at the cost of duplicated data and receivers that now maintain state. Event sourcing records every state change as an event so the full state can be rebuilt by reprocessing the log, with the event store as the principal source of truth. CQRS separates the read model from the write model, and Fowler treats it as distinct from event sourcing even though the two are often merged in conversation.
His analogy for event sourcing is a version-control system: the commit log is the event store and the working copy is the current state. He also corrects two assumptions with it. Event processing does not have to be asynchronous, since a local commit is synchronous, and not everyone in an event-sourced system needs to read the log, since his text editor is ignorant of every commit in the source tree.
Event-driven architecture differs from a request/response API such as REST or RPC in who knows whom, not in how fast the call is. In request/response, the caller names the callee, asks a specific question, and waits for the answer, so the caller has to know the other service exists and has to handle it being down. In event-driven architecture, the producer names nothing, expects no answer, and the router decides who hears about it.
The practical consequence is coupling. Adding a fourth consumer to an event stream changes nothing about the producer, while adding a fourth downstream call to a request/response flow means editing the caller. That is also why event-driven architecture is often described as push-based, not poll-based. AWS makes the cost argument directly on its own page, noting that consumers receive events as they happen rather than continuously polling for changes, though it is worth remembering that AWS sells the routers.
An event is not a command. An event is a statement in the past tense that something happened. A command is an instruction addressed to a specific handler. Fowler names the failure mode where the two are mixed as the "passive-aggressive command": a message shaped like an event that the sender expects someone to act on. Related terms sit at different layers, too. A webhook is one transport for event notification, an HTTP callback rather than an architecture, and serverless is a compute and billing model that happens to pair well with events rather than a communication style.
The trade-offs of event-driven architecture are asynchrony, traceability, and the cost of durability, and AWS names all of them on its own event-driven architecture page alongside the benefits. The application has to tolerate work completing later rather than immediately. If every event must be processed, you need a durable event source, not a fire-and-forget channel. If you plan to rebuild state from events, that source has to be deduplicated and correctly ordered.
Traceability is the one that surprises teams. AWS notes that event flow can be tracked dynamically through monitoring services, but not statically through code analysis. Fowler describes the same problem from the design side in his 2017 article: the larger logical flow that spans several notifications is not explicit in any program text, so the only reliable way to see it is to watch a running system, which makes it harder to debug and to change safely.
Set against that, AWS argues that services scale and fail independently because each one is aware of the router, not each other, that you write no custom polling, filtering, or routing code, and that the router gives you one central place to audit event flow and apply access policies. Adoption interest is real but hard to size precisely. A 2024 Gartner poll cited in its Maturity Model for Event-Driven Architecture found that 68% of IT leaders planned to increase their usage of event-driven architecture.
In a content system, event-driven architecture means that publishing, updating, or deleting a piece of content emits an event that downstream systems react to, not that those systems ask on a timer whether anything changed. The producer is the content store, the event is a document lifecycle change, and the consumers are the jobs that translate, resize, re-index, notify, or sync that content somewhere else.
Sanity implements that triple directly. The Content Lake emits document events on create, update, delete, and publish. A Blueprint, a single `sanity.blueprint.ts` file kept in the repository beside your application code, declares which events route to which handler, and Sanity compares that file against what exists on deploy so the file is the source of truth. A Function is the consumer: a small, single-purpose piece of TypeScript running on Sanity's cloud infrastructure that receives the event, can read and write the dataset, traverse references, and call external services. Beyond document changes, Functions can be triggered by Media Library asset changes, Live Content sync tag invalidation, a cron schedule, or invocation from another function. The reference material lives in the Functions documentation and the Blueprints documentation.
This is the reason Sanity describes itself as the Content Operating System for the AI era rather than a publishing tool. Other systems bolt AI onto an existing publishing flow. Structured models, event-driven workflows, agents, and agent actions make the automation contextual and governable, so the repetitive work happens as a reaction to content changing and the team spends its time on the work.
Unlock New Possibilities with Sanity
With event-driven architecture under your belt, it's time to see what Sanity can do for you. Explore our features and tools to take your content to the next level.
Last updated: