Search⌘ K
AI Features

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 synchronouslyA service waits for another service to complete the request and then performs the required operation. or asynchronouslyA client, while requesting a service, does not wait for or expect an immediate response and can start doing something else. When a response is ready, it is sent to the service. communication. Asynchronous communication is often preferred because services generally should not block while waiting for responses, but it requires a decoupling layer to coordinate tasks between them.

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.

Request-response structure with synchronous services awaiting responses
Request-response structure with synchronous services awaiting responses

After success or failure, the response propagates back through each service in the path to the client.

Request-response structure with synchronous services having failure status
Request-response structure with synchronous services having failure status

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 event listenersClients or services interested in events generated in event-driven architecture. to react to specific events by performing tasks, with event-driven protocols handling delivery.

Subscribing and receiving notifications
Subscribing and receiving notifications

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 topicA category of events.. When an event is triggered, it is pushed to the queue, which broadcasts it to all connected services.

Event-driven architecture with event queues
Event-driven architecture with event queues

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.

Pub-sub event-driven architecture for file upload
Pub-sub event-driven architecture for file upload

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:

  1. The upload service submits a video event to the event queue.

  2. The queue responds with success, which the upload service relays to the client.

  3. The queue sends event details to the processing service (a subscriber to this event).

  4. After processing, the processing service generates new events for the compressed or formatted video and submits them to the queue.

  5. The notification service, subscribed to formatted video events, receives the ...