Introduction to Systems Architecture

Before we look at how financial technology (FinTech) is changing the world, we must understand how software is built. “Architecture” in software is exactly like architecture in construction: it is the foundational blueprint of how a system is put together. In this lesson, we will compare the old way of building banks (The Monolith) with the new way of building FinTech apps (Microservices).

1. Architectural Baseline: The Legacy Banking Monolith

Traditional, established banks (often called “incumbents”) run on what is known as a Monolithic Architecture. The word monolith means a “single, massive stone.” In software, it means the entire banking application is built as one giant, inseparable block of code.

Many of these systems were built decades ago in the 1970s and 1980s using an old programming language called COBOL, and they run on massive, expensive physical computers called Mainframes (like the IBM Z-Series).

Characteristics of a Monolithic Bank:

• Tightly Coupled Codebase (The “Spaghetti Code” Problem): In a monolith, every single function of the bank is woven into the exact same program. User login, checking account balances, calculating loan interest, and processing credit card swipes are all tangled together.
  • The Danger: Because everything is connected, a small mistake by a programmer updating the “loan interest” code can accidentally cause a memory leak that crashes the “user login” system. If one part breaks, the entire bank goes offline.
• Vertical Scaling (Buying a Bigger Server): When a bank gets more customers, their computer systems have to work harder. “Scaling” is how a system handles growth. Monoliths are forced to scale vertically. This means the only way to handle more traffic is to buy a physically larger, more expensive mainframe computer—adding more CPU (processing power) and RAM (memory) to that single machine.
  • The Danger: There is a physical limit to how big a single computer can get. Furthermore, relying on one giant machine creates a Single Point of Failure (SPOF). If that one mainframe catches fire or loses power, the whole bank stops working.
• Shared Data Layer (The Traffic Jam): Monolithic banks store all their information in a single, massive relational database. Imagine a single, giant physical ledger book for the entire bank.
  • The Danger: Every time a module needs to read or write data, it goes to this single book. If millions of people are trying to check their balances, transfer money, and apply for loans at the same time, it creates a massive I/O (Input/Output) bottleneck. The system forces transactions to wait in line (database locking), which causes severe transaction delays and lagging apps during peak hours.

2. The Paradigm Shift: Cloud-Native Microservices

Modern FinTech companies (like Monzo, Revolut, or Stripe) do not use mainframes or monoliths. They build software using Cloud-Native Microservices.

Instead of building one giant application, they build dozens or hundreds of tiny, independent applications (microservices) that talk to each other over the internet using APIs (Application Programming Interfaces—essentially messengers that carry data between software). This is done using a strategy called Domain-Driven Design (DDD), where the technology is strictly organized by business function.

Characteristics of Microservices:

• Decoupled Architecture (The “Food Court” Analogy): Instead of one giant restaurant kitchen trying to cook every type of food (a monolith), microservices operate like a food court. The FinTech app is split into independent services. You have a distinct PaymentProcessingService, a UserProfileService, and an AuthService (for logging in). If the UserProfileService crashes, users can still log in and send payments because the other services are completely separate.

• • Containerization & Orchestration: How do you manage hundreds of tiny applications? You put them in “containers.”
    • Docker (The Container): A technology that packages a single microservice with only the exact files and tools it needs to run. It acts like a standardized steel shipping container.
    • Kubernetes (The Orchestrator): A management system that acts like the crane operator at a shipping port. Kubernetes constantly monitors the containers. If a container crashes, Kubernetes automatically deletes it and spins up a fresh, healthy copy in seconds without human intervention (self-healing).
  • Horizontal Scaling (Cloning the Servers): Instead of buying one giant, expensive computer (Vertical Scaling), FinTechs scale horizontally by renting thousands of cheap, virtual servers in the cloud (like Amazon Web Services or Google Cloud).

The Benefit: If it is payday and login requests spike by 500%, Kubernetes will automatically “clone” the AuthService container, creating 50 new copies to handle the rush of traffic. Meanwhile, it keeps the LoanOriginationService at just 2 copies to save money. When the rush is over, it deletes the extra copies.

3. Data Persistence and Database-per-Service Architecture

To make these microservices truly independent, FinTechs must abandon the single, massive shared database. They use a Database-per-Service model. This means every microservice has its own private, isolated database. No other service is allowed to touch it directly; they must ask for data via APIs.

Because each service has its own database, developers use Polyglot Persistence—a fancy term meaning “choosing the perfect type of database for the specific job.”

• In-Memory Key-Value Stores (e.g., Redis): Used by the AuthService. Redis stores data directly in the computer’s temporary memory (RAM) rather than on a hard drive. It is incredibly fast but not permanent. It is perfect for checking if a user’s session token (login status) is currently valid.

• • Relational Databases (e.g., MySQL or PostgreSQL): Used by the TransactionLedgerService. These are traditional, strict databases organized into tables, rows, and columns. They are used for financial ledgers because they enforce ACID properties, an absolute requirement for handling money:
    • Atomicity: A transaction is “all or nothing.” If you send money, deducting it from your account and adding it to your friend’s account is one action. If the addition fails, the deduction is instantly cancelled.
    • Consistency: Data must obey the rules (e.g., an account balance cannot drop below zero unless there is an overdraft facility).
    • Isolation: If two transactions happen at the exact same microsecond, they are queued and executed one after another so they don’t corrupt the math.
    • Durability: Once a transaction is complete, it is permanently saved. Even if someone pulls the plug on the server, the data is safe.

• Column-Oriented Data Warehouses: Used by the AnalyticsService. Instead of storing data row-by-row, it stores data column-by-column. This makes it incredibly fast for a data scientist to calculate things like “the total sum of all transactions in London over the last year” without slowing down the live application where customers are currently tapping their cards.

4. Resolving Distributed Transactions in Finance

The hardest part about having a Database-per-Service model is keeping all the isolated databases synchronized.

Imagine you buy a coffee using a FinTech app. The system needs to check if you are not a fraudster (FraudDatabase), deduct your money (LedgerDatabase), and send a receipt (NotificationDatabase).

Old monoliths used a Two-Phase Commit (2PC), where the system would literally lock all the databases, perform the math, and unlock them. In modern, high-speed cloud systems with millions of users, locking databases creates unacceptable traffic jams. FinTechs solve this using the Saga Pattern.

• • The Saga Pattern Mechanism: A Saga is a chain reaction of small, local events.

• The LedgerService deducts $5 and publishes a digital message: “Money Deducted.”

• The FraudService hears this message, runs a check, and publishes: “Fraud Check Failed. Suspicious Location.”

• Compensating Transactions (The Automated Undo): Because the LedgerService already deducted the money in its isolated database, it cannot simply “roll back” the clock. Instead, the Saga triggers a Compensating Transaction. This is an automated reverse entry. The system automatically creates a new transaction that refunds the $5 back to the user’s ledger, effectively restoring the system to its correct, original state without ever having to lock the entire database system.

5. The CAP Theorem in Financial Systems

Every FinTech system is bound by an inescapable law of computer science called the CAP Theorem. It states that a distributed cloud system can only guarantee two out of the following three traits at any given time:

1. Consistency (C): Every time you look at the data, it is 100% accurate and up-to-date. If you deposit $10 in New York, and a second later look at your app in Tokyo, it shows the $10.
2. Availability (A): The system always responds to your request, even if the data might be slightly outdated. The app never shows a “System Down” error.
3. Partition Tolerance (P): The system continues to operate even if a network cable is cut and the servers temporarily cannot talk to each other.

Because cloud systems rely on internet networks, network failures are unavoidable. Therefore, FinTechs must always choose Partition Tolerance (P). This leaves architects with a choice: do they want the system to be Consistent (C) or Available (A)?

FinTechs choose CP (Consistency and Partition Tolerance): In core banking ledgers, absolute accuracy is more important than uptime. If the network between two FinTech databases goes down, the system will intentionally choose to be unavailable (rejecting your transaction and showing an error screen) rather than risk being inconsistent.

Why? If the system chose Availability over Consistency (AP), you could transfer $1,000 to a friend on your phone, and because the databases aren’t syncing, you could quickly use your physical debit card to spend that same $1,000 at a store before the system caught up. This is called the “Double-Spend Problem.” In finance, a declined card (temporary unavailability) is vastly preferred over losing money to inconsistent data.