Microservices

Microservices are a way of designing software in which an application is built as a collection of small services, each responsible for one business function, each running as its own process and each deployed and scaled separately. The services communicate over a network, through programming interfaces or messages, and each normally owns its own data. The opposite approach is the monolith, a single program containing all functions and sharing one database.

In financial services the style is associated with payment processors, digital banks, card issuing platforms and wallet providers built since the mid-2010s, and with the modernisation of older banking systems. A payment platform lends itself to this division because its functions differ sharply in load, in how often they change and in how strictly they must be secured.

A typical processor might run separate services for merchant onboarding, the public API, tokenization and card data storage, fraud scoring, routing to acquirers, the ledger, payouts, disputes, notifications and reporting. Requests from merchants arrive at an API gateway, which authenticates the caller and forwards each request to the service that handles it.

When a merchant submits a card payment, the payment service calls the token service to retrieve the card details, asks the fraud service for a decision, and passes the transaction to the routing service, which selects an acquirer connection. These calls are synchronous because the shopper is waiting. Once the result is known, the payment service publishes an event to a message queue, and the ledger, notification and reporting services each react in their own time. This combination of direct calls for the urgent path and event-driven architecture for everything else is the usual pattern.

• Independent scaling. Authorization traffic peaks on shopping holidays while reporting does not. Each service can be given the capacity it needs, which cloud computing makes straightforward.
• Fault isolation. If the reporting service fails, payments continue. Good design keeps a fault in one area from reducing the uptime of the core payment path.
• Smaller compliance scope. Only the services that handle card numbers need to sit inside the cardholder data environment. Keeping card data in a small, tightly controlled group of services reduces the part of the system assessed under the PCI DSS.
• Faster change. Teams release their own services without waiting for a company-wide release. A new payment method or acquirer connection can be added as a new service or adapter.
• Regional deployment. Services holding regulated data can be run in a particular country to meet local storage rules, while others remain shared.

The hardest issue for financial systems is that a business operation now spans several databases. In a monolith, debiting one account and crediting another can be wrapped in a single database transaction that either completes entirely or not at all. Across services there is no such guarantee. A payout service might mark a payout as sent while the ledger service, called a moment later, is unavailable.

Designers handle this in several ways. Money movements are usually concentrated in one ledger service that keeps the transactional guarantees internally. Multi-step operations are organised as sagas, sequences in which each step has a compensating action that undoes it if a later step fails. Every call that moves money is made safe to repeat through idempotency, since networks time out and callers retry. Reconciliation between services, comparing what each believes happened, is run continuously as a safety net.

Each network call between services adds delay and a chance of failure, so a deep chain of calls increases payment processing latency on a path that has strict time limits. Engineers set timeouts, use circuit breakers that stop calling a failing service, and define fallback behaviour, for example approving low-risk payments if the fraud service does not answer in time.

Operating hundreds of services requires automation for deployment, monitoring and tracing a single payment across many components. Security work grows too: services must authenticate to one another, and each connection is a possible point of attack. Testing is harder, because behaviour depends on the interaction of many versions running at once. A badly divided system, in which services cannot function without one another, has the drawbacks of both styles and is often called a distributed monolith.

Established banks commonly apply the approach gradually, building new services around an existing core system and moving functions out of it one at a time. Newer core banking and card processing products are sold as sets of services with open interfaces, which lets a bank replace one component without the rest. Supervisors pay attention to the results: operational resilience rules in the European Union and the United Kingdom require firms to map the systems and suppliers that support important services and to show that they can recover from failures, which is easier when dependencies between components are explicit. Smaller firms often conclude that a well-structured monolith is sufficient until scale or team size demands otherwise.