MicroServices Coordination – 3

Two-Phase Commit (2PC): All or Nothing 🏛️

2PC is a protocol used to achieve atomic transactions across distributed systems. It guarantees that all participating services either commit their part of the transaction or they all abort. It works, as the name suggests, in two phases managed by a central transaction coordinator.

1. Phase 1: Prepare (The Vote). The coordinator asks every participant: “Are you ready to commit?” Each participant checks if it can perform the action and locks the necessary resources. It then votes “Yes” or “No”.
2. Phase 2: Commit (The Verdict).
   • If all participants voted “Yes”, the coordinator sends a “Commit” command to all of them.
   • If any participant voted “No” (or timed out), the coordinator sends an “Abort” command to all of them.

The biggest problem with 2PC is that it’s a blocking protocol. If the coordinator fails after the prepare phase but before the commit phase, all participants are left in limbo, holding onto locked resources until the coordinator recovers. Because of this, it’s rarely used in modern, high-availability microservice architectures.

C# Example: Simulating a 2PC Flow

This is a conceptual simulation. In the real world, you’d use a transaction coordinator like Microsoft DTC (Distributed Transaction Coordinator), but this illustrates the logic.

// --- The Transaction Coordinator ---
public class TransactionCoordinator
{
    private readonly List<IParticipant> _participants;

    public TransactionCoordinator(params IParticipant[] participants)
    {
        _participants = new List<IParticipant>(participants);
    }

    public bool ExecuteTransaction()
    {
        // --- PHASE 1: PREPARE ---
        Console.WriteLine("Coordinator: Starting PREPARE phase...");
        var votes = new List<bool>();
        foreach (var p in _participants)
        {
            votes.Add(p.Prepare());
        }

        // --- PHASE 2: COMMIT / ABORT ---
        if (votes.All(v => v == true))
        {
            Console.WriteLine("Coordinator: All participants prepared. Committing...");
            foreach (var p in _participants) { p.Commit(); }
            return true;
        }
        else
        {
            Console.WriteLine("Coordinator: A participant failed to prepare. Aborting...");
            foreach (var p in _participants) { p.Abort(); }
            return false;
        }
    }
}

// --- Interface for all participants ---
public interface IParticipant
{
    bool Prepare();
    void Commit();
    void Abort();
}

// --- Example Participant (e.g., a Database Service) ---
public class DatabaseServiceParticipant : IParticipant
{
    private bool _transactionState = false;

    public bool Prepare()
    {
        Console.WriteLine("DB Service: Resources locked. Ready to commit. Voting YES.");
        // In reality, begin a DB transaction and hold it open
        return true; // Return false to simulate a failure
    }
    
    public void Commit()
    {
        Console.WriteLine("DB Service: Commit command received. Finalizing transaction.");
        // Commit the DB transaction
        _transactionState = true;
    }

    public void Abort()
    {
        Console.WriteLine("DB Service: Abort command received. Rolling back transaction.");
        // Rollback the DB transaction
        _transactionState = false;
    }
}

Three-Phase Commit (3PC): The Non-Blocking Improvement 🛡️

3PC is an extension of 2PC designed to fix its blocking problem. It introduces a third phase that helps the system reach a decision even if the coordinator fails.

1. Phase 1: Prepare. Same as 2PC. The coordinator asks participants if they are ready.
2. Phase 2: Pre-Commit. If all participants voted “Yes” in the prepare phase, the coordinator sends a “Pre-Commit” message. This signals that everyone has agreed and the commit is definitely going to happen. Participants acknowledge this and are now ready to commit.
3. Phase 3: Commit. After receiving acknowledgements for the Pre-Commit phase, the coordinator sends the final “Commit” message.

How does this help? If the coordinator fails during the Pre-Commit phase, participants can time out and communicate with each other. If any participant has received a Pre-Commit message, they know it’s safe to go ahead and commit the transaction without waiting for the coordinator. This makes it non-blocking but adds significant network overhead and complexity, so it’s also very rarely used in practice.

C# Example: Simulating a 3PC Flow

public class ThreePhaseCoordinator
{
    private readonly List<IParticipant3PC> _participants;

    public ThreePhaseCoordinator(params IParticipant3PC[] participants) { _participants = new List<IParticipant3PC>(participants); }

    public bool ExecuteTransaction()
    {
        // --- PHASE 1: PREPARE ---
        Console.WriteLine("Coordinator: ==> PREPARE");
        if (!_participants.All(p => p.Prepare()))
        {
            Console.WriteLine("Coordinator: A participant failed. ABORTING.");
            _participants.ForEach(p => p.Abort());
            return false;
        }

        // --- PHASE 2: PRE-COMMIT ---
        Console.WriteLine("Coordinator: ==> PRE-COMMIT");
        if (!_participants.All(p => p.PreCommit()))
        {
             // If this phase fails, we still abort
            Console.WriteLine("Coordinator: A participant failed pre-commit. ABORTING.");
            _participants.ForEach(p => p.Abort());
            return false;
        }

        // --- PHASE 3: DO-COMMIT ---
        Console.WriteLine("Coordinator: ==> DO-COMMIT");
        _participants.ForEach(p => p.Commit());
        return true;
    }
}

public interface IParticipant3PC
{
    bool Prepare();
    bool PreCommit();
    void Commit();
    void Abort();
}

public class ServiceParticipant3PC : IParticipant3PC
{
    public bool Prepare() { Console.WriteLine("Participant: Preparing... YES"); return true; }
    public bool PreCommit() 
    {
        Console.WriteLine("Participant: Pre-committing... ACK");
        // At this point, the participant knows the transaction will eventually commit
        return true; 
    }
    public void Commit() { Console.WriteLine("Participant: Finalizing commit."); }
    public void Abort() { Console.WriteLine("Participant: Aborting."); }
}

Conclusion: Choosing the Right Strategy for Your Microservices

Navigating transaction coordination in a microservices architecture requires a fundamental shift away from the ACID guarantees of monolithic systems toward a model that embraces eventual consistency and resilience. There is no single “best” solution; the right choice depends entirely on the specific needs of your business process.

• Synchronous patterns (2PC/3PC) offer the allure of strong, atomic consistency but come at the high cost of tight coupling and blocking behavior. They are generally a poor fit for modern, cloud-native applications where availability and performance are paramount. Their use is limited to niche scenarios where immediate, absolute consistency across all nodes is a non-negotiable requirement.
• The Saga pattern has emerged as the de facto standard for managing complex, long-running business transactions in microservices. It prioritizes availability and loose coupling by breaking down a global transaction into a series of independent, local transactions that are coordinated through asynchronous messaging.
  • Choreography offers the ultimate in loose coupling and is excellent for simple, linear workflows where services can react to each other’s events without a central point of failure. However, its decentralized nature can make the overall process difficult to observe and debug.
  • Orchestration provides a clear, centralized, and manageable workflow, making it ideal for complex processes with conditional logic, multiple steps, and a need for robust error handling and compensation logic. The trade-off is a dependency on the orchestrator, which must be designed to be resilient.

Ultimately, the decision comes down to a trade-off between consistency, coupling, and operational complexity. For most distributed systems, the flexibility and resilience of the Saga pattern, particularly the clarity offered by Orchestration, provide the most balanced and scalable approach to maintaining data consistency across service boundaries.