Building a robust Payments service

Idempotence is executing the same action multiple times, but the result is as if the operation was applied just once.

Example: Double tapping a post multiple times on Instagram does not increase the like count. It just increases the first time and by 1.

Idempotence becomes extremely critical when money is involved. If A wants to transfer money to B, the transfer should happen just once. If due for any reason, the payment is implicitly retried, the funds will be deducted twice, which is unacceptable.

Why would a transaction repeat?

Before we talk about idempotence, it is important to understand why it would repeat in the first place.

Consider a situation where the payments service initiated a payment with a Payment Gateway, the money got deducted, but the payments service did not get the response. This would make the Payments service retry the API call, which would lead to a double deduction.

Implementing idempotence

Check and Update: Weave everything with a single ID.

The idea is to retry only after checking if the payment is processed or not. But how do we do this? The implementation is pretty simple- a global payment ID that weaves all the services and parties together.

The flow is:

1. The payments service calls the PG and generates a unique Payment ID
2. Payments service passes this ID to the end-user and all involved services
3. Payments service initiates the payment with Payment Gateway with this ID specifying the transfer between A and B
4. If there are any failures, the Payment service retries and in that request specifies the Payment ID
5. Using the payment ID, the payment gateway checks if the transfer was indeed done or not and would transfer only when it was not done

Although we talked about the Payments service here, this approach of implementing idempotence is pretty common across all the use cases. The core idea is to have a single ID (acting as the Idempotence Key) weaving all the involved services and parties together.

Here's the video of my explaining this in-depth ?? do check it out

Idempotence is an extremely critical property that we must consider while implementing an API or designing a microservice. The situation becomes even more critical when the money is involved - ensuring no matter how many times the user or internal service retries, the amount is transferred just once between the two users in one transaction.

This video looks at idempotence, why there is even a need for it, and, more importantly, one common implementation approach commonly observed in payments services.

Outline:

• 00:00 What is Idempotence?
• 02:32 Examples where Idempotence is relevant
• 04:06 Why do we even need to retry?
• 07:18 Implementation Approach 1: Do not retry
• 09:45 Implementation Approach 1: Check and Update

You can also

• Subscribe to the YT Channel Asli Engineering
• Download the notes
• Listen to this on the go on Spotify

Thank you so much for reading ?? If you found this helpful, do spread the word about it on social media; it would mean the world to me.

You can also follow me on your favourite social media LinkedIn, and Twitter.

Yours truly,

Arpit

arpitbhayani.me

Until next time, stay awesome :)

I teach a course on System Design where you'll learn how to intuitively design scalable systems. The course will help you

• become a better engineer
• ace your technical discussions
• get you acquainted with a massive spectrum of topics ranging from Storage Engines, High-throughput systems, to super-clever algorithms behind them.

I have compressed my ~10 years of work experience into this course, and aim to accelerate your engineering growth 100x. To date, the course is trusted by 600+ engineers from 10 different countries and here you can find what they say about the course.

Together, we will build some of the most amazing systems and dissect them to understand the intricate details. You can find the week-by-week curriculum and topics, benefits, testimonials, and other information here https://arpitbhayani.me/masterclass.