Jacob Troutman

← Decision log / Case file DR-02

ShippedC# · .NET · MQTT

Redesigned money-order printing so a failed print refunds the customer automatically

TL;DR6 min read

Problem

Printing a money order is slow and can fail partway. The old flow waited on the printer and had no clean way back from a failed print.

Decision

Run it as a saga: totaling continues while printing runs asynchronously, and a failed print triggers its own refund transaction.

Outcome

A failed print now refunds the customer automatically, verified on real money-order hardware.

Role Senior developerStack C#, .NET, MQTT
01

Context

A convenience-store chain was replacing its monolithic point-of-sale system with microservices.

The services talk over MQTT. I was a senior developer on a team of about 15, consulting through Momentum3, and I owned money orders end to end, from business rules to printing on real store hardware.

Conductor
Coordinates a sale across the other services.
Transaction
Totals the sale and records each money order.
Hardware
Drives the money-order printer at the counter.
UI
Shows the cashier what happened and what to do next.
02

Problem

Printing is slow and can fail partway, and the old flow had no clean way back.

Totaling the transaction waited on the printer, so the register sat blocked during every print. When a print failed, the failure tangled with the normal path. In payments, a failure can’t leave the customer charged for a document they never got.

03

Options

I weighed keeping printing inside the transaction against splitting the flow into steps that each recover on their own.

Option ARejected

Keep printing in the transaction

Simplest to change. The register still blocks while it prints, and every failure still runs through the happy path.

Option BChosen

Run it as a saga

Separate steps, each with its own recovery. More moving parts, but a failed print has one clear place to go.

04

Decision

I redesigned the flow in the conductor service as a saga.

  1. Totaling continues while printing runs asynchronously.
  2. The print timeout scales with the number of documents, so a large order isn’t cut off early.
  3. Failed prints go down their own path and trigger an automatic refund transaction.
  4. A low-document alert warns the store before the printer runs out.
05

Outcome

A failed print now refunds the customer automatically, in the same flow.

Money orders shipped with configurable limits, no refunds after printing, employee-ID verification, and fees as sub-line items.

06

What I'd tell an interviewer

  1. 01

    The design question was "what happens when step three fails?"

    The saga answers that before anyone asks. Each step knows how to recover, so a failure never falls through to the happy path.

  2. 02

    I started with the easiest test, not the hardest.

    Writing out every branch first, then testing from the top down, got me unstuck when the hardest test kept stalling.