Payments Academy
Active-active architecture PAYMENT OPERATIONS STARTED LIVE 01 Active-active architecture - foundation of a real-time payment platform ACTIVE 02 Stateless services - because no payment state is trapped inside QUEUED 03 Latency budget and the ten-second limit - must be spent carefully QUEUED 04 Screening and balance - checks, for example, can run at the same QUEUED 05 Monitoring and automated recovery - design itself, because failures happen QUEUED 06 Untested failover risk - bank that has never tested its failover will QUEUED Active-active architecture is the foundation of a real-time payment platform, because it keeps two or more data centres processing live traffic at the same time. Step 1 of 6 Active-active architecture STARTED Active-active architecture foundation of a real-time payment platform ACTIVE Stateless services because no payment state is trapped inside QUEUED Latency budget and the ten-second limit must be spent carefully QUEUED Screening and balance checks, for example, can run at the same QUEUED Monitoring and automated recovery design itself, because failures happen even QUEUED Untested failover risk bank that has never tested its failover will QUEUED Active-active architecture is the foundation of a real-time payment platform, because it keeps two or more data centres processing live traffic at the same time.
Stateless services make failover fast PAYMENT OPERATIONS IN PROGRESS LIVE 01 Active-active architecture - foundation of a real-time payment platform DONE 02 Stateless services - because no payment state is trapped inside ACTIVE 03 Latency budget and the ten-second limit - must be spent carefully QUEUED 04 Screening and balance - checks, for example, can run at the same QUEUED 05 Monitoring and automated recovery - design itself, because failures happen QUEUED 06 Untested failover risk - bank that has never tested its failover will QUEUED Stateless services make failover fast, because no payment state is trapped inside a single server. Step 2 of 6 Stateless services make failover fast IN PROGRESS Active-active architecture foundation of a real-time payment platform DONE Stateless services because no payment state is trapped inside ACTIVE Latency budget and the ten-second limit must be spent carefully QUEUED Screening and balance checks, for example, can run at the same QUEUED Monitoring and automated recovery design itself, because failures happen even QUEUED Untested failover risk bank that has never tested its failover will QUEUED Stateless services make failover fast, because no payment state is trapped inside a single server.
Latency budget and the ten-second limit PAYMENT OPERATIONS IN PROGRESS LIVE 01 Active-active architecture - foundation of a real-time payment platform DONE 02 Stateless services - because no payment state is trapped inside DONE 03 Latency budget and the ten-second limit - must be spent carefully ACTIVE 04 Screening and balance - checks, for example, can run at the same QUEUED 05 Monitoring and automated recovery - design itself, because failures happen QUEUED 06 Untested failover risk - bank that has never tested its failover will QUEUED Latency is a budget that must be spent carefully, because every millisecond counts toward the ten-second limit. Step 3 of 6 Latency budget and the ten-second limit IN PROGRESS Active-active architecture foundation of a real-time payment platform DONE Stateless services because no payment state is trapped inside DONE Latency budget and the ten-second limit must be spent carefully ACTIVE Screening and balance checks, for example, can run at the same QUEUED Monitoring and automated recovery design itself, because failures happen even QUEUED Untested failover risk bank that has never tested its failover will QUEUED Latency is a budget that must be spent carefully, because every millisecond counts toward the ten-second limit.
Screening and balance PAYMENT OPERATIONS IN PROGRESS LIVE 01 Active-active architecture - foundation of a real-time payment platform DONE 02 Stateless services - because no payment state is trapped inside DONE 03 Latency budget and the ten-second limit - must be spent carefully DONE 04 Screening and balance - checks, for example, can run at the same ACTIVE 05 Monitoring and automated recovery - design itself, because failures happen QUEUED 06 Untested failover risk - bank that has never tested its failover will QUEUED Screening and balance checks, for example, can run at the same time rather than one after another. Step 4 of 6 Screening and balance IN PROGRESS Active-active architecture foundation of a real-time payment platform DONE Stateless services because no payment state is trapped inside DONE Latency budget and the ten-second limit must be spent carefully DONE Screening and balance checks, for example, can run at the same ACTIVE Monitoring and automated recovery design itself, because failures happen even QUEUED Untested failover risk bank that has never tested its failover will QUEUED Screening and balance checks, for example, can run at the same time rather than one after another.
Monitoring and automated recovery matter as much PAYMENT OPERATIONS IN PROGRESS LIVE 01 Active-active architecture - foundation of a real-time payment platform DONE 02 Stateless services - because no payment state is trapped inside DONE 03 Latency budget and the ten-second limit - must be spent carefully DONE 04 Screening and balance - checks, for example, can run at the same DONE 05 Monitoring and automated recovery - design itself, because failures happen ACTIVE 06 Untested failover risk - bank that has never tested its failover will QUEUED Monitoring and automated recovery matter as much as the design itself, because failures happen even in the best systems. Step 5 of 6 Monitoring and automated recovery matter as much IN PROGRESS Active-active architecture foundation of a real-time payment platform DONE Stateless services because no payment state is trapped inside DONE Latency budget and the ten-second limit must be spent carefully DONE Screening and balance checks, for example, can run at the same DONE Monitoring and automated recovery design itself, because failures happen even ACTIVE Untested failover risk bank that has never tested its failover will QUEUED Monitoring and automated recovery matter as much as the design itself, because failures happen even in the best systems.
Untested failover risk PAYMENT OPERATIONS COMPLETE LIVE 01 Active-active architecture - foundation of a real-time payment platform DONE 02 Stateless services - because no payment state is trapped inside DONE 03 Latency budget and the ten-second limit - must be spent carefully DONE 04 Screening and balance - checks, for example, can run at the same DONE 05 Monitoring and automated recovery - design itself, because failures happen DONE 06 Untested failover risk - bank that has never tested its failover will ACTIVE A bank that has never tested its failover will discover its flaws at the worst possible moment, during a real outage. Step 6 of 6 Untested failover risk COMPLETE Active-active architecture foundation of a real-time payment platform DONE Stateless services because no payment state is trapped inside DONE Latency budget and the ten-second limit must be spent carefully DONE Screening and balance checks, for example, can run at the same DONE Monitoring and automated recovery design itself, because failures happen even DONE Untested failover risk bank that has never tested its failover will ACTIVE A bank that has never tested its failover will discover its flaws at the worst possible moment, during a real outage.

Key points of this lesson, in order.

0:00 / 3:12 Step 1 of 6

Designing for 24/7 Availability and Low Latency

Real-Time Payments Architecture, Lesson 2 of 7, Narration 3:12, D05 Domestic payment systems

SchemeQueue

What you will learn

Your objective. By the end of this lesson, you will be able to explain designing for 24/7 availability and low latency. Active-active architecture is the foundation of a real-time payment platform, because it keeps two or more data centres processing live traffic at the same time.

Why it matters. This matters because the next payment product you work on may use one of these technologies. Knowing what is real and what is still a proposal is what separates a good analyst from a confused one.

Chapter objective: Learner designs real-time payments architecture, covering 24 by 7 availability, instant clearing, liquidity, and failure handling, and explains how it differs from batch systems. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Active-active architecture
  • Stateless services make failover fast
  • Latency budget and the ten-second limit
  • Screening and balance
  • Monitoring and automated recovery matter as much
  • Untested failover risk

Key terms

Scheme: A card or payment network that sets the rules, standards and fees for transactions between issuers and acquirers.

Queue: A holding area in a payment system where payments wait for sufficient funds or for their turn to settle.

Banking architecture diagram showing Designing for 24/7 Availability and Low Latency.

Practise this lesson

Exercise

Apply the concept in this lesson to a real banking scenario.

Use the definition, the example and the key points in this lesson.

  1. What to do. Explain the concept in your own words, give a banking example with an amount, and state what goes wrong if it is misunderstood.

Correct result. A correct answer names the concept accurately, uses a realistic banking example with a concrete amount, and identifies the consequence of getting it wrong.

Why. Understanding is not memorising a definition. It is being able to explain it, apply it, and spot the failure it prevents.

Check your understanding

Practice question

A bank is designing a real time payments service that must settle instantly, 24 hours a day, seven days a week. What is the hardest design problem?

Takeaway and next step

What to remember

Some banks separate the fast transactional store from the reporting store, so heavy reporting queries never slow down live payments.

Follow USD 750 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "What Real-Time Really Means".

Transcript and full text

Show transcript

Active-active architecture is the foundation of a real-time payment platform, because it keeps two or more data centres processing live traffic at the same time. If one centre fails, the other continues without waiting for a manual switch. A bank in Singapore, for example, might run payment services in two centres ten kilometres apart, each able to handle the full daily load of 2 million transactions. Traffic is split between them by a load balancer that checks the health of every service every five seconds. When a centre stops responding, traffic moves in under thirty seconds, and customers notice nothing except a slightly longer wait. Stateless services make failover fast, because no payment state is trapped inside a single server. Each request carries everything the service needs, or the service reads shared state from a fast data store. A payment validation service can therefore restart on a new server and pick up the next request immediately. Session data, such as the progress of a USD 750 transfer from initiation to confirmation, lives in a replicated cache or database rather than in server memory. This design also makes scaling simple, because new servers can be added during a peak, such as the morning rush when salary payments flood in. Latency is a budget that must be spent carefully, because every millisecond counts toward the ten-second limit. A database query that takes 200 milliseconds is acceptable, but five such queries in sequence consume a full second. Architects therefore cache reference data, such as sort codes, BICs, and scheme limits, in memory, so lookups take less than five milliseconds. They use connection pools to avoid opening a new database connection for each payment, and they call downstream services in parallel where the calls do not depend on each other. Screening and balance checks, for example, can run at the same time rather than one after another. The database is often the hardest part of a low-latency design, because every payment must update an account balance safely. A single relational database can handle thousands of updates per second, but a peak of 5,000 payments per second needs partitioning by account or by region. Some banks separate the fast transactional store from the reporting store, so heavy reporting queries never slow down live payments. Write-ahead logs and synchronous replication protect against data loss, but they add latency, so teams tune the replication distance and test the trade-off between speed and durability under real load before launch. Monitoring and automated recovery matter as much as the design itself, because failures happen even in the best systems. Every service reports its latency, error rate, and queue depth to a central dashboard, with alerts that fire when a payment takes longer than three seconds. Automated runbooks restart a failing service, drain traffic from a sick node, or switch to a standby database without human intervention. Chaos testing, where engineers deliberately shut down a data centre during a quiet period, proves that failover actually works. A bank that has never tested its failover will discover its flaws at the worst possible moment, during a real outage.

Active-active architecture is the foundation of a real-time payment platform, because it keeps two or more data centres processing live traffic at the same time. If one centre fails, the other continues without waiting for a manual switch. A bank in Singapore, for example, might run payment services in two centres ten kilometres apart, each able to handle the full daily load of 2 million transactions. Traffic is split between them by a load balancer that checks the health of every service every five seconds. When a centre stops responding, traffic moves in under thirty seconds, and customers notice nothing except a slightly longer wait.

Stateless services make failover fast, because no payment state is trapped inside a single server. Each request carries everything the service needs, or the service reads shared state from a fast data store. A payment validation service can therefore restart on a new server and pick up the next request immediately. Session data, such as the progress of a USD 750 transfer from initiation to confirmation, lives in a replicated cache or database rather than in server memory. This design also makes scaling simple, because new servers can be added during a peak, such as the morning rush when salary payments flood in.

Latency is a budget that must be spent carefully, because every millisecond counts toward the ten-second limit. A database query that takes 200 milliseconds is acceptable, but five such queries in sequence consume a full second. Architects therefore cache reference data, such as sort codes, BICs, and scheme limits, in memory, so lookups take less than five milliseconds. They use connection pools to avoid opening a new database connection for each payment, and they call downstream services in parallel where the calls do not depend on each other. Screening and balance checks, for example, can run at the same time rather than one after another.

The database is often the hardest part of a low-latency design, because every payment must update an account balance safely. A single relational database can handle thousands of updates per second, but a peak of 5,000 payments per second needs partitioning by account or by region. Some banks separate the fast transactional store from the reporting store, so heavy reporting queries never slow down live payments. Write-ahead logs and synchronous replication protect against data loss, but they add latency, so teams tune the replication distance and test the trade-off between speed and durability under real load before launch.

Monitoring and automated recovery matter as much as the design itself, because failures happen even in the best systems. Every service reports its latency, error rate, and queue depth to a central dashboard, with alerts that fire when a payment takes longer than three seconds. Automated runbooks restart a failing service, drain traffic from a sick node, or switch to a standby database without human intervention. Chaos testing, where engineers deliberately shut down a data centre during a quiet period, proves that failover actually works. A bank that has never tested its failover will discover its flaws at the worst possible moment, during a real outage.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.