Distributed Systems on Vubon Notes

Saga Pattern: Handling Distributed Transactions in Microservices

Wed, 03 Jun 2026 00:00:00 +0000

Whenever microservices enter a system design discussion, one question always comes to my mind:

What happens when a transaction succeeds in one service but fails in another?

Let’s take a payment system as an example.

Imagine a user initiates a $100 transfer. The workflow looks like this:

Transfer Service creates the transaction ✅
Wallet Service deducts $100 from the user’s balance ✅
Bank Service sends the transfer request ❌

Now we have a problem.

No-Op Update Pattern: State-Driven Idempotent Updates

Sun, 24 May 2026 11:00:00 +0000

After exploring idempotency keys, I came across another pattern that deserves more attention: the No-Op Update Pattern.

The idea is simple, but the mindset behind it is what makes it powerful.

Instead of treating every update request as something that must trigger work, you first ask a more important question:

Does this request actually change the state?

If the answer is no, the system should do nothing and return the current state.

System Design Interview: Partial Failure & Durability

Fri, 08 May 2026 00:00:00 +0000

After talking about idempotency, I thought I’d share another good follow-up question:

“What happens if your service crashes in the middle of a request?”

Let’s say:

transfer record inserted ✅
ledger update started ❌
database connection drops
service dies

Now you have partial data.

And in payment systems, partial success is usually worse than failure.

The first answer most people give #

👉 Use database transactions (ACID).

System Design Interview: Idempotency

Mon, 04 May 2026 11:00:00 +0000

Almost every candidate faces this question during a system design interview:

How do you handle duplicate transactions?

Most people answer: Idempotency key + Cache.

To be honest — that’s a good start.

But the real lesson comes when you build an actual payment system.

Duplicates are normal behavior #

In distributed systems, duplicates are not edge cases. They are normal behavior.

Duplicates can originate from anywhere:

client double-clicks
mobile retry on timeout
API gateway retries
reverse proxies
silent network failures
third-party timeouts

So the problem is not if duplicates happen.

System Design Interview Prep — Series Introduction

Mon, 04 May 2026 10:00:00 +0000

System design interviews are tough. Not because the questions are impossible - but because they’re open-ended, and most people don’t know where to start.

After years of building distributed systems in FinTech, I’ve been on both sides of the table. I know what interviewers are actually looking for, and it’s not buzzwords. It’s trade-offs, real-world thinking, and knowing why something works, not just that it works.

So I’m putting together this series — practical write-ups on the topics that come up again and again. No fluff, just the stuff that matters.