CAP Theorem: Why the Real Choice is CP vs AP and How It Shapes Microservices

package com.bank.model;

/**
 * Illustrates CAP properties with banking examples.
 */
public class CAPProperties {

    // CONSISTENCY: Rajesh deposits 50000 at Branch A.
    // Any read from Branch B immediately returns the updated balance.
    // If Branch B returns an old balance, consistency is violated.

    // AVAILABILITY: Rajesh walks into Branch B and asks for his balance.
    // Branch B must respond, even if the answer might be stale.
    // If Branch B says "sorry, system down", availability is violated.

    // PARTITION TOLERANCE: The network between Branch A and B is down.
    // The system must still function (either CP or AP behavior).
}

package com.bank.service;

import java.math.BigDecimal;
import java.sql.*;
import java.util.logging.Logger;

/**
 * CP behavior: the account service refuses rather than
 * risk returning a stale balance during a partition.
 */
public class CPAccountService {

    private static final Logger LOG = Logger.getLogger(
        CPAccountService.class.getName());

    private final Connection primaryConnection;

    public CPAccountService(Connection primaryConnection) {
        this.primaryConnection = primaryConnection;
    }

    public BigDecimal getBalance(String accountId) throws SQLException {
        // Reads from primary only: consistent but may be unavailable
        // during a partition if the primary is unreachable
        String sql = "SELECT balance FROM accounts WHERE account_id = ?";
        try (PreparedStatement ps = primaryConnection.prepareStatement(sql)) {
            ps.setString(1, accountId);
            try (ResultSet rs = ps.executeQuery()) {
                if (rs.next()) {
                    return rs.getBigDecimal("balance");
                }
                throw new SQLException("Account not found: " + accountId);
            }
        }
        // If primaryConnection fails (partition), this throws an exception
        // rather than returning stale data from a replica.
    }
}

package com.bank.service;

import java.util.logging.Logger;

/**
 * AP behavior: the feed service returns whatever data
 * is available locally, even if it is stale.
 */
public class APFeedService {

    private static final Logger LOG = Logger.getLogger(
        APFeedService.class.getName());

    public String getActivityFeed(String customerId) {
        // Reads from the nearest replica: always available
        // but may be stale during a partition
        LOG.info("Serving feed from local replica for " + customerId);
        return "Recent activity (may be slightly stale)";
        // Conflicts resolved later via last-write-wins or CRDT
    }
}

package com.bank.service;

import java.math.BigDecimal;
import java.util.logging.Logger;

/**
 * Pankaj's architecture: CP for money, AP for everything else.
 */
public class TransferOrchestrator {

    private static final Logger LOG = Logger.getLogger(
        TransferOrchestrator.class.getName());

    private final CPAccountService accountService;  // CP: strong consistency
    private final APFeedService feedService;         // AP: eventual consistency

    public TransferOrchestrator(CPAccountService accountService,
                                APFeedService feedService) {
        this.accountService = accountService;
        this.feedService = feedService;
    }

    public void transfer(String sourceId, String targetId, BigDecimal amount) {
        // Step 1: CP - debit and credit must be strongly consistent
        // Uses ACID transaction on the primary database
        LOG.info("Executing transfer with strong consistency");

        // Step 2: AP - notify feed asynchronously via Kafka event
        // The feed can lag a few seconds; that is acceptable
        LOG.info("Publishing transfer event for feed update (eventual consistency)");
    }
}

-- Practical example: saga pattern for cross-service transfer
-- Account Service (CP): debit locally with ACID
UPDATE accounts SET balance = balance - 10000.00
WHERE account_id = 'SAV2001' AND balance >= 10000.00;

-- If the credit service is unreachable (partition):
-- CP choice: abort and compensate (reverse the debit)
-- AP choice: queue the credit and process it when the partition heals

-- The saga pattern uses compensating actions:
-- 1. Debit source (committed)
-- 2. Try credit target
-- 3. If credit fails, compensate: reverse the debit