Context
Flume Digital Agency was running the Woolworths Mother’s Day campaign. The campaign needed a custom gift-carding system, and the campaign date was Mother’s Day.
That is the entire brief and the entire constraint. Mother’s Day does not move for anybody.
The problem
Campaign systems have an unusual risk profile. They carry a national retailer’s brand, they take a very large fraction of their total traffic inside a few hours, and then they are switched off. There is no soft launch and no second attempt.
The failure modes that matter aren’t the interesting ones. They’re duplicate card issuance under load, a transactional email queue that silently stalls, and a redemption code collision that only appears at volume.
What I did
I built the card issuance around idempotency from the first commit. Every issuance request carries a key; a retried or duplicated request returns the original card rather than minting a second one. This is unglamorous and it is the single reason the campaign didn’t generate a support incident.
Code generation used a cryptographically random alphabet with a check character, and a uniqueness constraint at the database level rather than in application code — because under concurrency, application-level uniqueness checks are a race condition with good intentions.
Email went through a queue with retry and a dead-letter path, so a slow send couldn’t block issuance and a failed send couldn’t vanish. Load was modelled against Flume’s traffic expectations, then tested at several times that, because campaign traffic forecasts are famously optimistic.
Then I stopped adding things. A campaign system needs to do one job perfectly for a short window. Every feature past that is risk with no upside.
The result
The system went from brief to live inside a week and ran the campaign without downtime or a duplicate-issuance incident.
It is the kind of work that is invisible when it goes right, which is the point. Flume have contracted me for lead development work repeatedly since.
