File API Design Evaluation and Latency Budget

Introduction

Now that the key choices for a file API service have been made, let's discuss how we meet the non-functional requirements and see situations where some tweaks or changes might be needed to make the service more efficient.

Non-functional requirements

Let's discuss the non-functional requirements identified in the introduction lesson one by one.

Reliability

We make shadow copies of service components (API gateways, application servers, UFMS, etc.) that can be subject to a single point of failure (SPOF). We also generate multiple copies of the data and store them in regionally distributed data centers as backups. This allows us to respond to any natural disaster. Moreover, we use circuit breakers and appropriate monitoring mechanisms to detect service-critical issues and resolve them in advance.

Security

Our API allows authorized access to authenticated users only. Users can log in either by authenticating directly with their credentials or by using OAuth 2.0 and OIDC using an authorization code and PKCE flow to obtain a third-party access token. Access tokens reduce the risk of data leakage and loss when dealing with third-party applications. Moreover, the stored data is always encrypted, so the attacker can’t extract any valuable information from it, even if it is compromised. We assume our system also has an appropriate intrusion detection mechanism to identify and recover from bad situations.