Amol Sood

The tricky part wasn’t moving money once. It was that money can’t always get from A to B directly. Some transfers need to pass through an intermediate stop first. Moving from a bank account into savings, for example, has to land in the spending wallet on the way through. I called each of those individual stops a “hop,” and some transfers need one, others need two, depending purely on where the money’s coming from and where it’s going.

Rather than write custom logic for every possible path, I split the problem in two: what the user asked for (I called this an instruction, one per user request) and what actually has to happen to fulfill it (a series of transactions, one per hop). A one-hop transfer is one instruction, one transaction. A two-hop transfer is one instruction, two transactions, processed in order. Same underlying machinery either way.

Every transfer comes through one door with a single switch: wait for the whole thing end-to-end, or get an answer the moment it’s recorded and let the system work through the hops in the background. Either way, the caller hears back with the transfer’s status. Both run the exact same logic underneath; the “wait for it” version just chains the same steps together synchronously instead of queueing them.

And because a bank transfer doesn’t settle instantly (it can take days), the system doesn’t sit there polling. It waits for a signal that a step actually completed, then automatically triggers the next hop itself. If a step fails for a reason that’s genuinely retryable, a self-healing job picks it back up without a human needing to notice, let alone intervene.