Stripe API Design Evaluation and Latency Budget

As we have seen, Stripe plays an important role in the payment ecosystem and makes the payment process smooth via the API endpoints we provided in the previous lesson. While we achieved different functional requirements through these endpoints, we still have to focus on the non-functional requirements we identified in the initial lesson. This lesson will describe how we achieve the non-functional requirements and different optimization strategies to improve the efficiency and response time of our service. Toward the end, we will also compute the response time of the Stripe API.

Non-functional requirements

The following section discusses how Stripe API meets the non-functional requirements.

Strong consistency

Due to the nature of the API that involves operations on critical data and financial data, strong consistency is paramount for the Stripe API. The Stripe API is strongly consistent and provides consistent data at every level by adopting the following measures:

• Exactly once semantics: Idempotency keys are used in the API call where the non-idempotent method needs to be used, such as the POST HTTP method. This way, we avoid multiple operations where only one operation needs to be performed.

• Reconciliation: The internal system's services periodically communicate with each other to compare their statuses to confirm that they are in agreement. According to some studies, this is the last line of defense in the payment system. Reconciliation not only improves the security of the payment system but also makes the system internally consistent.