McDonald’s Event-Driven Architecture

__omp_shell("")

McDonald's event-driven platform is interesting because it treats events as a product surface, not just an integration detail. In a large organisation, producers and consumers are built by different teams, in different regions, with different release cycles. If each team publishes whatever message shape it wants, the event bus quickly becomes a compatibility trap. The hard part is not putting Kafka in the middle. It is creating governance that lets hundreds of services change safely.

The event registry addresses that problem first. It defines schemas, versioning rules, and event ownership so producers and consumers have a shared contract. Without that registry, teams end up reverse-engineering topics from live traffic, which is fragile and slow. A registry also makes validation and compatibility checks possible before deployment rather than after a broken consumer has already reached production.

Custom SDKs solve the next layer of pain. A raw messaging client is usually not enough for enterprise adoption because every team then reimplements serialization, retries, dead-letter handling, telemetry, and security. Shared SDKs push those concerns into one maintained path. That improves reliability, but it also standardises behaviour. If every producer emits tracing headers and every consumer reports failures in a consistent format, platform teams can operate the estate rather than a pile of one-off integrations.

The event gateway exists because event platforms still need perimeter control. Not every caller should be able to publish every event or subscribe to every topic. Authentication, authorisation, and policy enforcement matter just as much in asynchronous systems as they do in HTTP APIs. In some ways they matter more, because an incorrect event can be fanned out to many consumers before the mistake is noticed.

The regional architecture shows the scaling strategy. Domain-based sharding lets teams separate unrelated traffic and scale the busiest domains independently. Running managed Kafka clusters such as MSK per domain or per regional boundary reduces blast radius and keeps throughput planning realistic. Autoscaling based on broker metrics helps absorb traffic growth, but scaling an event platform is not just adding nodes. Partition rebalancing, consumer lag, ordering guarantees, and cross-region replication all need careful handling.

What stands out in this design is that operational tooling is treated as a first-class component. Utilities for repairing events, managing cluster health, and handling administrative workflows are essential because event systems fail in awkward ways. A bad message can be durable, replayable, and globally distributed.

That is the core lesson. Event-driven architecture scales when the organisation standardises contracts, client behaviour, and operational control around the bus. The message broker is necessary infrastructure, but the platform only becomes usable when governance and tooling are built around it.