Design a Pub-Sub Service
Explore the design of a pub-sub service that enables asynchronous event-driven communication between microservices. Understand core components like publishers, middleware, and subscribers. Learn about REST API endpoints for topic management, WebSub protocol for event delivery, and strategies for scalability, security, and low latency.
From request-response to event-driven communication
Microservices architectures demand connectivity between subsystems, achieved through either
Most client-server interactions follow the request-response model using HTTP with synchronous communication: the client initiates a request, and the server responds after completing all operations. Consider a video upload service in which the client sends a file through an API gateway to an upload service, which routes it to processing and notification services. The client waits for a success or failure status until the entire chain completes.
After success or failure, the response propagates back through each service in the path to the client.
Challenges of the request-response model
Partial failure cascades: If the upload and processing services succeed but the notification service fails, the client receives a failure response and must retry, increasing latency. Meanwhile, the databases updated by successful services require a rollback, adding overhead across the entire chain.
Costly integration of new services: Each new service must be explicitly integrated with all coordinating services, increasing overhead as complexity grows.
No server-initiated updates: The model cannot efficiently inform clients about backend events that occur independently of client requests.
These limitations motivate event-driven architecture (EDA), which decouples microservices by centering communication around events. In EDA, a client subscribes once to an event type, and the server pushes notifications as events occur rather than requiring explicit polling. EDA enables
EDA introduces an event queue between microservices, which act as both producers and consumers. All consumers connect to this queue and wait for events in a
In this model, service A triggers an event and adds it to the queue; services B, C, and D consume it if relevant. Scaling is straightforward: a new service simply connects to the event queue. Updates broadcast automatically to consumers whenever an event occurs.
However, EDA's broadcast model lacks selective event delivery. Events reach all potential listeners indiscriminately. This limitation leads directly to the pub-sub model, which pushes events only to targeted, subscribed destinations.
The pub-sub model and its inner structure
The pub-sub (publisher-subscriber) model implements EDA with three core components:
Publishers: Content producers that trigger events that are sent to the middleware.
Middleware: A broker or hub that decouples publishers and subscribers, distributing content from publishers to the appropriate subscribers.
Subscribers: Consumers that receive updates for subscribed topics whenever a relevant event is triggered.
In the video upload example, the workflow proceeds as follows:
The upload service submits a video event to the event queue.
The queue responds with success, which the upload service relays to the client.
The queue sends event details to the processing service (a subscriber to this event).
After processing, the processing service generates new events for the compressed or formatted video and submits them to the queue.
The notification service, subscribed to formatted video events, receives the ...