A transaction layer built for a retailer that never closes

IKEA's transaction handling had grown the way transaction handling always grows inside a large retailer — method by method, market by market, each addition reasonable on its own and unmanageable in aggregate. The question was whether a single layer could sit underneath all of it.

It was framed as a prototype, which is the honest framing: the job was to find out whether the design held before anyone committed a roadmap to it.

We built the transaction management layer in NestJS with MongoDB behind it, designed so that a payment method is a plug-in concern rather than a branch in a growing conditional. The interesting constraint was global reach — the same layer had to behave predictably across markets with genuinely different payment habits.

Infrastructure was automated with Terraform from the first commit, and CI/CD ran through GitHub Actions onto Kubernetes. That is not incidental to a prototype: the point of a prototype is to learn fast, and you cannot learn fast if deploying takes a morning.

The team worked in close loops with IKEA's own engineers to validate the design against real scale assumptions rather than hoped-for ones.

The prototype demonstrated a single transaction layer capable of handling IKEA's payment methods with fault isolation between them, on infrastructure that could be recreated from source.

The habits from this engagement — infrastructure as code, pipelines before features — are the ones we now start every platform build with.