Cloud and deployment architecture for payment platforms

A payment platform that runs in the cloud does not run on one server. It runs across regions, availability zones, containers and networks, and the architecture must be designed so that a failure in one place does not stop payments everywhere. A region is a geographic area, for example eu-west-1 in Ireland. An availability zone is an isolated data centre inside a region, with its own power, cooling and network. A payment platform runs its services in at least two availability zones, so that if one zone fails, the other takes over. A platform that runs in only one zone has a single point of failure, and a single point of failure is not acceptable for payments. The services themselves run in containers, which are lightweight, isolated packages that hold the code and its dependencies. A container orchestrator, usually Kubernetes, decides where each container runs, restarts it if it crashes, and scales the number of containers up or down with load. On a quiet Sunday morning, the platform might run three copies of the validation service. On a busy Monday morning, when thousands of salary payments arrive at once, it might run thirty. The orchestrator scales automatically, so the platform handles the peak without a human intervening. The database is the exception: it cannot be scaled the same way, so it runs as a managed service with replication across zones, and the platform is designed so that the database is never the bottleneck. Deploying a new version of a payment platform is risky, because a bad deploy can stop payments. The platform therefore uses zero downtime deployment. In a blue-green deploy, the new version runs alongside the old version, traffic is switched to the new version gradually, and if anything goes wrong, traffic switches back to the old version in seconds. In a canary deploy, the new version receives a small percentage of traffic first, for example five percent, and if it behaves correctly, the percentage is increased step by step. The deploy is never a big bang, and it is never irreversible. Every deploy is also versioned and logged, so that operations can say exactly which version was running when a payment failed. Data residency is a constraint that shapes every cloud decision in payments. Some regulators require that payment data stays inside a specific country or region. A bank operating in the European Union must keep personal data inside the EU, and a bank in India must keep certain payment data inside India. The cloud architecture must therefore place data in the right region, and must not replicate it to a region where it is not allowed. That affects where the database runs, where the backups are stored, and where the logs are sent. A design that ignores data residency will fail a regulatory review, even if it is technically excellent. The shared responsibility model decides who is responsible for what. The cloud provider is responsible for the physical data centre, the network, and the hypervisor. The bank is responsible for the application, the data, the access controls, and the configuration. If a payment is lost because a container was misconfigured, that is the bank responsibility, not the provider. If a payment is lost because a data centre flooded, that is the provider responsibility, and the bank must have a disaster recovery plan that moves to another region. For a business analyst, the cloud architecture requirements are therefore about resilience, data residency, deployment safety and responsibility, not about which cloud provider is fashionable. The question is always the same: if this part fails, do payments stop, and if they do, how fast can we recover.