Why Centralized Architecture Evolves to Microservices: Banking Insights

Background and Motivation

In cloud‑native environments, especially in banking, the shift from monolithic, centralized systems to microservices is driven by the need for elasticity, faster iteration, and reduced operational overhead. The talk examines why architectures evolve, how Internet‑scale systems have changed over time, and the implications for distributed transactions.

Traditional Centralized Architecture

Typical banking transaction processing follows a layered flow: channel layer → customer‑service (often SOA) layer → application business layer . Core services such as deposit, loan, and settlement are tightly coupled, making fault isolation costly.

IBM mainframe solutions illustrate this model:

AOR (Application OR) and TOR (Transaction OR) built on CICS middleware.

CF provides a cache layer.

Db2 serves as the relational database.

High‑availability is achieved through hardware redundancy (multiple CPUs, memory, I/O paths) and software services, emphasizing vertical scaling (scale‑up) and strong ACID consistency for OLTP workloads.

Microservice Architecture

Microservices enable autonomous, small‑team development and deployment. According to Conway’s law, the organization’s structure shapes system design, leading to:

Horizontal service decomposition (each service owns a bounded context).

Vertical business‑domain division (each service implements a specific business capability).

Distributed data storage (each service manages its own data store).

Key supporting concepts include Service Mesh (for traffic management, security, observability) and cloud‑native deployment patterns (containers, orchestration platforms).

Distributed Transaction Models

Two primary consistency models are used in microservice environments:

Rigid (ACID) Transactions

Implemented via 2‑Phase Commit (2PC) or XA protocols in middleware such as CICS, Tuxedo, DB2, and Oracle. The protocol consists of:

Prepare phase : the coordinator asks all participants to lock resources and prepare to commit.

Commit phase : if all participants respond positively, the coordinator issues a commit; otherwise a rollback is issued.

Advantages: strong consistency and immediate visibility of transaction results, which is essential for banking ledger integrity. Drawbacks: blocking during the prepare phase, increased latency, and complex failure handling (e.g., coordinator crash, participant hangs).

Flexible (BASE) Transactions

Emphasize eventual consistency and high availability. Common patterns:

TCC (Try‑Confirm‑Cancel) : each participant implements three operations— Try (reserve resources), Confirm (finalize), and Cancel (release). The global transaction succeeds only if all Try calls succeed; otherwise compensating Cancel actions are executed.

Saga : decomposes a long‑running transaction into a series of local transactions with compensating actions. Two execution styles exist:

Orchestration‑based Saga (central coordinator drives the flow).

Choreography‑based Saga (services emit events and react autonomously).

Saga guarantees atomicity at the business level but does not provide isolation; idempotency and compensation design are critical.

Asynchronous Messaging : events are persisted in a message broker (e.g., Kafka, Pulsar) and processed by downstream services, achieving eventual consistency without a global lock.

Consensus algorithms such as Paxos, Raft, and ZAB are used by distributed databases to achieve replicated state without blocking, offering higher throughput for read‑heavy workloads.

Practical Recommendations

Design microservice systems to **minimize distributed transaction scopes**. Prefer local transactions and eventual consistency wherever possible.

When strong consistency is mandatory (e.g., financial ledger updates), **use 2PC** or XA‑compatible middleware, but be prepared for its performance impact and the need for robust failure‑recovery logic.

For most business processes, adopt **BASE‑style patterns**: implement TCC or Saga with well‑defined compensations, and leverage asynchronous message queues for decoupled state propagation.

Integrate a **Service Mesh** (e.g., Istio, Linkerd) to handle cross‑service security, traffic routing, and observability, which simplifies the operational overhead of many microservices.

Ensure **idempotent APIs** and **compensation logic** to handle retries and partial failures gracefully.

By aligning architectural choices with business requirements—strong consistency for critical accounting, eventual consistency for user‑facing workflows—organizations can transition from heavyweight centralized mainframes to scalable, cloud‑native microservice ecosystems while maintaining data integrity.