Does Netflix use event-driven architecture?
Yes. Netflix runs one of the largest event-driven systems in production: its Keystone data pipeline moves hundreds of billions of events a day through Apache Kafka, and services across the company consume those events asynchronously rather than calling each other for the data. Netflix is not event-driven everywhere, though, and the parts that stayed synchronous are as instructive as the parts that did not.
What Netflix runs on events
Keystone is the piece Netflix has written about most. Playback telemetry, UI interactions, and service logs are produced to Kafka topics, then routed to their destinations: object storage for batch analysis, search clusters for operational queries, and stream processors for anything that has to react within seconds. The producers do not know or care who reads them. Adding a new consumer means subscribing to a topic, not filing a ticket with the team that owns the source.
That decoupling is the whole point of event-driven architecture, and at Netflix's volume it is also a survival mechanism. A recommendation job that falls behind does not slow down the service emitting the events, it just develops a lag it can work off later. Netflix built its Mantis platform on the same idea for operational data, processing event streams to spot problems while they are happening instead of after a batch job finishes.
What Netflix kept synchronous
Pressing play is not an event. When a member starts a title, the client calls the API layer and waits, and those calls fan out to backing services over ordinary request-response protocols like gRPC. Somebody is staring at a loading spinner, so the system needs an answer now, not eventual consistency in a few hundred milliseconds.
Netflix also built Conductor, a workflow orchestration engine, precisely because some multi-step processes need a coordinator that knows the current state of the whole workflow. Pure choreography, where each service reacts to events and nobody holds the overall picture, is hard to debug when step four of nine silently stops firing. The practical answer at Netflix was to use both: events where systems should be decoupled, orchestration where a process needs to be observable end to end.
What this means for a smaller system
The pattern is copyable, the scale is not. Kafka earns its operational cost when you have many consumers, replay requirements, and producers that must never block. At a few thousand events a day, a database table with a worker polling it will do the same job with a fraction of the maintenance, a comparison we work through in webhooks vs Kafka.
What does transfer is the discipline that makes event systems survivable. Every event delivery mechanism worth using is at-least-once, so consumers have to be idempotent and treat duplicates as normal traffic. Events that cannot be processed need somewhere to go, which is what a dead letter queue is for, because a poison message that blocks a partition takes the pipeline down with it. And event names become an interface the moment a second team consumes them, so they are worth designing as carefully as an API; our guide to event naming conventions covers the tradeoffs. Where the boundary between events and services should sit is a longer discussion, which we cover in event-driven architecture vs microservices.
Events that leave your company
Kafka topics and internal streams work because both sides are yours. You control the consumers, the retention, and the deploy schedule. That stops being true the moment the consumer is a customer's server, sitting behind their firewall and going down for their maintenance windows.
That is the problem webhooks solve: an HTTP POST to a URL the customer registered, signed so they can verify it came from you, retried with backoff when their endpoint is unavailable. Netflix-scale internal eventing and outbound webhooks are the same architectural instinct applied on either side of a company boundary. If you are building the outbound half, Svix handles the signing, retries, and delivery logs so that part is not another distributed system for your team to run.