Have you heard of Store and Forward? It’s a resiliency design prevalent in card & bank payments, telecommunications, and other industries.

The concept is that rather than failing a request when a dependency is down, store it, and send the request when it is back up.

🤔 How it works:

We have two services, Service A, which is highly dependent on Service B to process requests.

Traditionally, when Service B is down, Service A would have no choice but to reject requests with a failure.

With the Store and Forward design, when Service B is unavailable, Service A will reply to the request with a “degraded processing” (rejecting it, accepting it, or saying, “We’ll let you know later”).

But before replying to the request, it is “stored” somewhere that can be accessed quickly, such as a cache, a queue, a database, etc.

When Service B is back up, Service A will “forward” the stored requests to Service B.

🥹 What I like about this design pattern:

It accepts that failures are going to occur because everything fails.

Rather than creating “retry storms,” it adds more intelligence to the process, only sending requests to Service B when it’s back online.

It ensures that no request is lost, even in significant outages.

But this design pattern isn’t without complexity.

Blind retries are easy; you keep retrying.

But with Store and Forward, you need to:

🛑 Know when Service B is unavailable

🧠 Add logic around degraded processing

✅ Detect when Service B has recovered

🤹 Figure out the best way to dequeue the stored requests

While more complex than blind retries, store and forward is a great resiliency design for when every request matters.

In payments, where reliability and fast responses are critical, as is accuracy, the complexity of store-and-forward designs is a worthwhile trade-off.