Pub-Sub API Design Evaluation and Latency Budget

Introduction

In the previous lesson, we created the API for the pub-sub service to meet the functional requirements identified earlier. This lesson focuses on different techniques employed to meet the non-functional requirements and the tradeoffs between them. We also estimate the response time of the pub-sub API to analyze if the latency of the API is in the ideal range. Moreover, after analyzing all the aspects of API design, we will discuss the notification service as a use case of the pub-sub service.

Non-functional requirements

The following section discusses how the pub-sub service meets the non-functional requirements:

Scalability and availability

The replication of brokers and clusters enhances the scalability and aids in the availability of the API. Partitioning helps to distribute messages or events to multiple queues based on topics or message type. This enables the system to scale horizontally and distribute the workload across multiple brokers without blocking or slowing down the service. Moreover, asynchronous processing of events from different partitions allows the pub-sub service to efficiently scale and handle peak loads without compromising performance. Load balancing and horizontal scaling also enable the pub-sub service to scale to handle numerous events and users and remain available.

We can also limit the requests for publishers and subscribers to avoid overwhelming the system with numerous requests. Similarly, we monitor the API to receive timely alerts to mitigate any issues in the API.

Security

The users can request a list of available topics to subscribe to without logging in. In this case, we prefer that the clients have an API key as a security check. The user must be logged in to send a subscription request by providing an API key and an access token. To authenticate subscription requests from the intended user, we introduced verification of intent (VOI) as an extra security layer. VOI is used to avoid subscription requests from unauthorized users on behalf of a subscriber. This is done by sending a verification request to the callBack URL of a subscriber. It’s a GET request embedded with a challenge parameter that a subscriber fulfills by echoing the challenge in response. More details on VOI are available hereVOI