Messenger API Design Evaluation and Latency Budget

Introduction

Modeling an adequate API is a complex task that involves fine-tuning different technical dimensions. These technical dimensions have different parameters to be optimized, and their tradeoffs must be considered. In this lesson, we’ll discuss how non-functional requirements can be achieved and what optimization decisions we need to take. We’ll also discuss the latency and response time of our proposed API of Messenger.

Non-functional requirements

The following section discusses how the messenger API meets the non-functional requirements:

Consistency

A chat application would require rolling out new features frequently, which needs periodic API versioning. We keep the endpoints, error messages, URL patterns, and relevant data entities uniformHaving a standard naming convention so that it is easy to map from one to the other. to achieve consistency. Moreover, during a chat, the messages must be delivered in sequence; therefore, we utilize the FIFO (First In, First Out) messaging queue with strict ordering.

Availability and disaster recovery

To enhance availability, we divide different responsibilities among various services and install redundant servers to avoid overburdening a single service. Furthermore, cascading failures are avoided using circuit breakers. We also provide sufficient chat servers and corresponding WebSocket managers to handle their mapping with clients. Therefore, even if a WebSocket connection fails with one chat server, the session is recreated, possibly with a different server. Moreover, the messages are stored on highly consistent and efficient database clusters, like HBase and MyRocks, Region replication is a feature that replicates the database of one region into another region. which provides high availability and reliability via region replicationRegion replication is a feature that replicates the database of one region into another region. .

Note: ...