American Express has redesigned parts of its payment-processing platform around independent “cells,” deterministic routing and tightly controlled failure boundaries to keep transactions moving even when services fail.
A card payment has very little tolerance for delay. Customers expect an approval or decline within seconds, which means the infrastructure behind that transaction must continue operating even when individual services or servers fail.
American Express has addressed that challenge with a cell-based architecture designed to isolate faults and keep payment processing available. Instead of running the entire payment journey through one tightly connected system, transactions are routed through independent processing units that contain the services, databases and supporting infrastructure needed to complete the work.
The architecture reflects a broader financial-infrastructure principle: reliability is not only about preventing failure, but about ensuring that one failure does not spread across the entire system.
Why Payment Systems Need Strong Failure Isolation
American Express began modernising parts of its core payments platform onto cloud-native infrastructure in 2018. That required a different engineering assumption from traditional hardware environments: individual servers can disappear, and applications need to be designed around that possibility.
The company considered several architectural patterns, but real-time payments leave little room for slow asynchronous processing. A monolithic design also creates scaling and resilience problems because one failure can affect a much larger part of the system.
The result was a structure built around independent cells.
A Cell Is a Complete Payment-Processing Unit
In American Express’s architecture, each cell contains everything required to process a transaction within its own boundary.
That includes microservices, databases, DNS and supporting infrastructure. Each cell can deploy independently, process payments on its own and be removed from rotation during maintenance or an incident without bringing down the rest of the platform.
The most important point is that a cell is defined by its failure boundary.
Microservices divide software by function. Cells divide infrastructure by failure. One cell can contain many microservices, but the critical transaction path does not rely on synchronous calls into another cell.
That separation helps prevent a local outage from becoming a global one.
Data Stays Close to the Transaction
Keeping cells independent creates a difficult data problem.
Some information changes rarely, such as country codes, merchant category codes and certain reference data. American Express pushes this information into every cell before transactions need it, avoiding a last-minute lookup against a central system.
Dynamic data is more complicated because it can change with every transaction. Replicating it between cells creates a short period in which different cells may hold different versions.
American Express handles this by reversing the usual approach.
Rather than always moving data to the transaction, the system can route the transaction to the cell holding the relevant data.
The Global Transaction Router Sits at the Centre
This routing is managed by a component called the Global Transaction Router.
Every transaction enters a cell through the router, and any transaction moving between cells must return through it. Cells are not allowed to communicate directly with one another.
That creates a globally connected payments mesh while preserving independent failure domains.
American Express deliberately keeps the router simple. It contains minimal business logic, avoids persistent state and depends on as few other services as possible. Configuration is kept in memory and updated asynchronously, while logging can drop non-critical records rather than block live transaction processing.
The design principle is clear: if one component becomes a chokepoint, it should be simple enough to remain dependable.
What Happens When a Service Fails Mid-Transaction?
The architecture becomes most interesting when a transaction is already being processed and one of the required services fails.
American Express uses an orchestrated microservices model in which an orchestrator manages the sequence of work and monitors service health. If a critical service becomes unavailable, the transaction is sent back to the Global Transaction Router, which selects a healthy cell.
The new cell does not resume where the previous one stopped.
Instead, it starts the transaction again from the original input.
That means some work may be repeated, but the second cell never needs to read state from the failed one. This avoids the shared-state dependency that could otherwise make multiple cells fail together.
For a payment flow measured in hundreds of milliseconds, repeating a small amount of work can be a better trade-off than introducing structural fragility.
The “Point of No Return” Comes Late
A payment cannot be restarted indefinitely.
American Express therefore defines a point beyond which rerouting is no longer safe. While a transaction remains inside the core payments ecosystem, it may still be moved to another cell. Once it has reached an external institution such as a card issuer, the transaction remains on that path.
The system places this irreversible step as late as possible, maximising the period in which a failure can still be recovered from.
For transaction types where late rerouting is not possible, the platform relies on idempotency, using unique identifiers so downstream systems can recognise and suppress duplicate attempts.
Reliability Comes With Trade-Offs
The architecture is not free of cost.
Maintaining isolated cells can duplicate services and increase operational complexity. Asynchronous logging means some non-critical observability data may be lost during heavy pressure, while global monitoring can lag because each cell records data locally before aggregation.
American Express accepts these costs because they reduce the blast radius of failures.
The system may experience more isolated component failures overall, but fewer of those failures can disrupt the platform as a whole.
What Financial Institutions Can Learn From the Model
The architecture highlights several lessons that extend beyond American Express.
First, resilient financial infrastructure depends on failure containment, not simply redundancy. A backup system is less useful if it depends on the same data, services or network paths as the system it is meant to replace.
Second, data architecture and routing strategy are closely linked. Sometimes maintaining consistency means routing transactions toward the correct data rather than replicating everything everywhere.
Third, critical infrastructure benefits from simplicity at its central chokepoints. American Express gives the Global Transaction Router enormous responsibility while deliberately limiting its logic and dependencies.
Finally, recovery design should match the economics of the transaction. In a real-time payment system, restarting a few hundred milliseconds of work can be preferable to building complex shared-state recovery.
A Different Way to Think About Financial Resilience
American Express’s model shows that payment reliability is increasingly being designed around the assumption that failures will happen.
The objective is therefore not to build one perfect system that never goes down, but to create many independent processing domains where faults can be isolated and transactions can continue elsewhere.
For financial institutions modernising legacy infrastructure, that distinction is increasingly important.
As payment volumes grow and more financial services move onto distributed cloud-native systems, architecture becomes part of operational risk management itself.
About American Express
American Express is a global payments and financial-services company providing card, merchant and payment-network services.
The architecture discussed here was described by American Express Distinguished Engineer Ben Cane in a technical discussion with ByteByteGo about how the company’s payment platform is designed for resilience and low-latency processing.
Source
- ByteByteGo — “Built for Reliability: How American Express Processes Payments at Scale”, published 8 September 2026, based on discussions with American Express engineering teams and Distinguished Engineer Ben Cane.
