CAP theorem: what properties should be preserved for a banking/financial system with a distributed microservice architecture?

The CAP theorem considers three properties of distributed systems: Consistency, Availability, and Partition Tolerance.

For a banking or financial system with a distributed microservices architecture, the typical priorities are:

• Consistency: It is critically important that data is always up-to-date and consistent, especially in operations involving money. Discrepancies in balances or transactions are unacceptable.

• Partition Tolerance: In distributed systems, network partitioning is inevitable, so the system must operate correctly and recover after such failures.

• Availability: Important, but in the financial sector, sometimes immediate availability can be sacrificed for consistency and security.

Thus, a banking system usually opts for CP — consistency and partition tolerance, sometimes with limited availability during failures. This means that during network partitions, the system may become temporarily unavailable to preserve data integrity.

Example: When transferring money between accounts, it is crucial that the amount is debited from one account and credited to another simultaneously, even if part of the system is unavailable.