You are building a fintech ledger system. You need to move funds from User A to User B. How do you implement this, and why might you choose a 'Saga Pattern' over a MongoDB Transaction for this specific use case?

Question

Accepted Answer

The choice between a MongoDB transaction and the Saga Pattern depends entirely on your architecture. If both User A and User B's accounts reside in the same database and service, a multi-document MongoDB transaction is the correct choice . However, if this fund movement spans multiple services (e.g., User A in a 'Payments Service' and User B in a 'Ledger Service'), a single MongoDB transaction cannot maintain atomicity across service boundaries. In this distributed scenario, you would choose the Saga Pattern . const mongoose = require('mongoose');

async function transferFunds(fromAccountId, toAccountId, amount) {
  const session = await mongoose.startSession();
  
  try {
    session.startTransaction();
    
    // All operations must happen within the same transaction
    const fromAccount = await Account.findOne({ _id: fromAccountId }).session(session);
    if (fromAccount.balance < amount) {
      throw new Error('Insufficient funds');
    }
    
    await Account.updateOne(
      { _id: fromAccountId },
      { $inc: { balance: -amount } },
      { session }
    );
    
    await Account.updateOne(
      { _id: toAccountId },
      { $inc: { balance: amount } },
      { session }
    );
    
    await Transaction.create([{
      from: fromAccountId,
      to: toAccountId,
      amount: amount,
      timestamp: new Date()
    }], { session });
    
    await session.commitTransaction();
    return { success: true };
  } catch (error) {
    await session.abortTransaction();
    throw error;
  } finally {
    session.endSession();
  }
} **Database per Service**: In microservices, each service has its own database. A MongoDB transaction cannot span the Ledger Service's database and the Payments Service's database. The Saga pattern is designed specifically for distributed transactions across multiple services . **No Distributed Locking**: Sagas use compensating transactions instead of locking resources across services. If a step fails, previous steps are undone via compensation (e.g., refunding a debit), rather than holding long-term distributed locks . **Eventual Consistency**: Fintech systems can tolerate milliseconds of inconsistency. The Saga pattern embraces eventual consistency, which is more scalable than the strict ACID consistency of a transaction . **Service Autonomy**: Each service in a saga maintains control over its own data. A central coordinator requests actions, but each service decides locally whether to commit or reject, preserving autonomy . // Conceptual Node.js Saga Orchestrator
class FundTransferSaga {
  async execute(fromAccountId, toAccountId, amount) {
    const sagaId = generateSagaId();
    const log = [];
    
    try {
      // Step 1: Debit from Payments Service
      const debit = await this.callService('payments', 'debit', {
        accountId: fromAccountId,
        amount,
        sagaId
      });
      log.push({ step: 'DEBIT', data: debit });
      
      // Step 2: Credit to Ledger Service
      const credit = await this.callService('ledger', 'credit', {
        accountId: toAccountId,
        amount,
        sagaId
      });
      log.push({ step: 'CREDIT', data: credit });
      
      // Step 3: Record transaction (optional third service)
      await this.callService('audit', 'record', {
        from: fromAccountId,
        to: toAccountId,
        amount,
        sagaId
      });
      
      return { success: true, sagaId };
    } catch (error) {
      // Compensate in reverse order
      await this.compensate(log.reverse());
      throw new Error(`Transfer failed: ${error.message}`);
    }
  }
  
  async compensate(log) {
    for (const entry of log) {
      if (entry.step === 'DEBIT') {
        // Refund the debit
        await this.callService('payments', 'credit', entry.data);
      }
      if (entry.step === 'CREDIT') {
        // Reverse the credit
        await this.callService('ledger', 'debit', entry.data);
      }
    }
  }
} If you are implementing a **single service** (e.g., all accounts in one collection), use the MongoDB transaction example above. This gives you ACID guarantees . If you are building a **microservices architecture** where account management is split across services, the Saga Pattern is the industry-standard approach for distributed transactions, ensuring data consistency without sacrificing service autonomy .

You are building a fintech ledger system. You need to move funds from User A to User B. How do you implement this, and why might you choose a 'Saga Pattern' over a MongoDB Transaction for this specific use case?

For a fintech ledger within a single service, implement using MongoDB's multi-document transactions for atomicity. However, if the fund movement spans multiple services, you would choose the Saga Pattern with compensating transactions to maintain eventual consistency without distributed locking.

You are building a fintech ledger system. You need to move funds from User A to User B. How do you implement this, and why might you choose a 'Saga Pattern' over a MongoDB Transaction for this specific use case?

For a fintech ledger within a single service, implement using MongoDB's multi-document transactions for atomicity. However, if the fund movement spans multiple services, you would choose the Saga Pattern with compensating transactions to maintain eventual consistency without distributed locking.

Scenario Questions

Follow-up Questions