Pub-Sub API Design Decisions

In the preceding lessons, we discussed the internal structure of the pub-sub service and the requirements to design an API for it. This lesson discusses how users and clients interact with the pub-sub service via the API gateway. Furthermore, we describe some design considerations for developing the pub-sub API service.

Design overview

We’ll discuss a high-level architecture of the pub-sub API in this section. The client/publisher sends an HTTP request to the API gateway. In the case of pub-sub, the request can be to list, create, delete, and subscribe to topics. Such requests coming from users are forwarded to the pub-sub service for handling after necessary authentication and authorization checks. For example, pub-sub can provide a list of available topics to the list request, whereas it can add a topic whenever the create request arrives. Requests are filtered to be placed in the appropriate queues. From there, they are pushed to the intended subscribers.

Note: The publishers and subscribers can be simple clients or other services. Also, a publisher can be a subscriber of any other topics and vice versa.

The following diagram gives details of the workflow, components, and services involved in a pub-sub service.

An overview of the components and services involved in the design of a pub-sub service is given in the following table:

Workflow

This section discusses how the components interact to fulfill different requested operations in a pub-sub service. Below is the workflow of the following operations: creating topics or publishing events, listing the topics, and subscribing or unsubscribing from the topic: ...