Best way to handle partial failures when calling several external APIs in one request?

[kevpoul]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code Search and Navigation

Body

Our endpoint needs to call three external services (payment, inventory, notification). If the payment succeeds but inventory fails, we end up with an inconsistent state – the user is charged but the order is not confirmed

Rolling back the payment is complex (refund API is asynchronous). What patterns can we use to keep data consistent without introducing a distributed transaction (like 2PC)? Examples in Go / Java / pseudo‑code appreciated

TY :D

[kevpoul]

HElp me someone

[vgartg]

You’ve described a classic case for the Saga pattern. Instead of a single atomic transaction, you break the operation into small steps, each with a compensating action (a rollback step)

Saga approach (example for your case)
Let’s define the steps:
Process payment → compensating action: refund
Reserve inventory → compensating action: release inventory
Send notification → compensating action: no‑op (or log a failed notification)
You run them in sequence. If step N fails, you run compensating actions for steps 1..(N-1) in reverse order

Pseudo‑code (simplified):

type Step struct {
    Action func() error
    Compensate func()
}

steps := []Step{
    {Action: chargeCard, Compensate: refundCard},
    {Action: reserveStock, Compensate: releaseStock},
    {Action: sendEmail, Compensate: func() {}},
}

func executeSaga(steps []Step) error {
    for i, step := range steps {
        if err := step.Action(); err != nil {
            // rollback previous steps
            for j := i-1; j >= 0; j-- {
                steps[j].Compensate()
            }
            return err
        }
    }
    return nil
}

Two execution models
A) Orchestration (central coordinator)
A single saga orchestrator knows all steps and calls them in order. Simple and great for small workflows (like yours). The downside: the orchestrator becomes a single point of logic

B) Choreography (event‑driven)
Each service emits events (e.g., PaymentProcessed) that trigger the next service. More decoupled but harder to debug and trace

Practical recommendations for your case
Use an outbox pattern with a message queue (RabbitMQ, Kafka, AWS SQS) to make saga steps reliable and retryable
Idempotency keys on all external calls – so that retrying a step doesn’t cause double charges
Make compensating actions idempotent too. A refund should be safe to call twice
Implement a dead‑letter queue for manual intervention when a compensating action also fails (e.g., refund API is down). Log the state and alert an operator

Alternative: transactional outbox without saga
If the external calls are not too critical, you can accept eventual consistency:

Store the intent in your local DB (pending_order)

Use a background worker to retry the failed step (inventory reservation) until success

After all steps succeed, mark the order as confirmed
But this doesn’t automatically refund the payment if inventory never becomes available – you’d need a timeout and then trigger refund

[typelop]

Sure!! 100%

[kevpoul]

Good. THX >3