American Express redesigned their payment processing platform around a cell-based architecture after moving to cloud infrastructure in 2018. The core problem: when a transaction hits a failing service, you can't just retry it in the same processing unit or move it elsewhere without creating fragile dependencies between units. Their solution treats each cell as a complete, independent copy of the entire payment stack—microservices, databases, DNS, everything needed to process a transaction from start to finish. A cell forms its own failure domain, so when something breaks inside it, the damage stays contained. The critical insight is that cells divide systems by failure boundaries, not by function like microservices do. One cell can contain many microservices, but what matters is that blocking calls between cells during transaction processing are forbidden. This keeps the system resilient when individual cells go down for maintenance or fail unexpectedly. The architecture hinges on data locality—each cell needs all the information it requires to make decisions without calling outside itself during the critical path. American Express handles three types of data differently. Immutable data gets set up once. Semi-static data like exchange rates and merchant codes changes slowly, so they push it out to every cell ahead of time rather than having transactions wait for cache misses. This avoids the cold cache penalty and keeps synchronous calls from leaving the cell boundary. Dynamic data that changes per transaction is the tricky part. Instead of replicating it constantly, they move transactions to where the data already lives through deterministic routing—the Global Transaction Router reads attributes from the transaction itself (partner, market, payment type) and sends it to the right cell without relying on load balancing or availability checks. The size of each cell requires careful judgment. American Express doesn't throw the entire enterprise into one cell. Instead, they draw boundaries around specific journeys—in payments, that means the minimum components needed to produce an immediate answer to the cardholder. The real-time transaction processing happens in one cell, while after-the-fact work like reconciliation can happen elsewhere. This separation matters because the customer waiting at checkout expects approval or decline within seconds. Everything about the architecture serves that single requirement: keeping latency low and ensuring the system keeps functioning even when parts of it fail.