Architecting Distributed Sagas with NestJS, Go, and gRPC

1. Introduction: The Dual-Write Problem in Heterogeneous Microservices

In a microservices architecture, maintaining transactional consistency is one of the most persistent engineering challenges. In a monolith, transactional integrity is guaranteed by database ACID properties: a single BEGIN TRANSACTION and COMMIT block ensures that either all operations succeed or all are rolled back. When this monolith is decomposed into isolated, heterogeneous microservices with private databases, this safety net disappears.

Engineers often attempt to solve this by writing to a local database and immediately publishing an event to a message broker. This is known as the dual-write problem. Because these two actions (database write and event publication) are not atomic, a network partition or process crash occurring between the database commit and the event dispatch results in an inconsistent system state. If the database commit succeeds but the message broker dispatch fails, the downstream microservices will never learn of the state change.

To avoid the dual-write pitfall, distributed transactions are required. Historically, two-phase commit (2PC) was utilized. However, 2PC is a blocking protocol; a coordinator must wait for confirmation from all participating resource managers. In a distributed network, this causes severe latency inflation, deadlocks, and single-point-of-failure vulnerability. If a single resource manager hangs or partition isolation occurs, the entire system blocks, severely impacting throughput.

Standard HTTP/REST-based microservice chains compound these issues. A chain of synchronous HTTP calls (Service A calling Service B, which in turn calls Service C) fails under network partitions due to cascading timeouts and lack of deterministic state recovery. If Service B times out, Service A cannot easily determine whether the request was processed or dropped before execution. Building robust, reliable applications under these constraints requires clear separation of duties and highly optimized communication interfaces. For companies building high-reliability platforms, electing to hire TypeScript developer talent with specific expertise in distributed patterns is essential to coordinate these complex microservice topologies.

In heterogeneous ecosystems—such as a NestJS/TypeScript stack handling business domain rules and web applications, combined with high-throughput Go services executing low-level system or stream processing—gRPC is the optimal communication medium. By utilizing HTTP/2 transport and Protocol Buffers, gRPC eliminates HTTP/1.1 serialization overhead and provides strict, contract-first communication. It allows the implementation of a Distributed Saga Pattern to coordinate complex, multi-step transactions without 2PC blocking bottlenecks.

2. Choosing the Architecture: Orchestration vs. Choreography

A distributed saga can be implemented using one of two patterns: event-driven choreography or centralized orchestration. Selecting the correct pattern depends on the transaction complexity, step count, and debugging requirements.

In Event-driven Choreography, there is no central controller. Each microservice executes its local transaction and publishes an event to a broker (e.g., RabbitMQ, Apache Kafka). Downstream services listen to these events, execute their respective local transactions, and publish subsequent events. While this pattern prevents a single point of failure and minimizes coupling, it has significant disadvantages as the business flow grows:

• Cognitive Overhead & Spaghetti Flows: Visualizing the complete transaction flow becomes difficult since the state machine is implicitly defined across multiple codebases.

• Cyclic Dependencies: Services must be aware of each other's events, which can lead to circular dependencies.

• Complex Error Handling: Coordinating a compensation sequence across many services requires complex event routing topologies.

In Orchestration, a dedicated service (the Saga Orchestrator) acts as a centralized controller. It manages the transaction lifecycle, explicitly triggers each step in the saga sequence via gRPC, and coordinates compensating actions if any step fails.

Orchestration is the preferred architecture for complex, multi-step transactions requiring strict step-by-step state verification. The orchestrator isolates the transaction topology, provides a centralized, deterministic state log, and simplifies debugging. It acts as an explicit state machine that routes steps, records executions to a persistent log, and triggers compensations in reverse order upon failure.

3. Designing the gRPC Contract (Protocol Buffers)

To orchestrate transactions between NestJS and Go microservices, we must define a strict API contract using Protocol Buffers (proto3). This contract specifies the endpoints, request payloads, and response structures for executing steps and triggers.

Below is the complete saga.proto schema. It defines the SagaCoordinator service, which the Go workers implement to process step commands and compensating actions, and the data structures necessary to track state execution.

syntax = "proto3";

package saga.v1;

option go_package = "github.com/staksoft/saga/v1;sagav1";

service SagaCoordinator {
  rpc ProcessStep (ProcessStepRequest) returns (ProcessStepResponse);
  rpc CompensateStep (CompensateStepRequest) returns (CompensateStepResponse);
}

message ProcessStepRequest {
  string saga_id = 1;
  string step_name = 2;
  bytes payload = 3;
  int32 execution_attempt = 4;
}

message ProcessStepResponse {
  bool success = 1;
  string error_message = 2;
  bytes result_data = 3;
}

message CompensateStepRequest {
  string saga_id = 1;
  string step_name = 2;
  bytes payload = 3;
}

message CompensateStepResponse {
  bool success = 1;
  string error_message = 2;
}

4. Implementing the NestJS Saga Orchestrator

The NestJS microservice acts as the Saga Orchestrator. It maintains a persistent transaction state log and routes requests to the Go microservice using gRPC. To prevent race conditions during concurrent transaction runs, we implement an optimized InnoDB schema in MySQL. This table utilizes explicit transactional locks to ensure that only one execution context can mutate the saga state at a time, avoiding common database deadlocks discussed in our analysis of WooCommerce and MySQL deadlock bottlenecks.

MySQL Database Migration (Saga Log)

CREATE TABLE `saga_logs` (
  `id` VARCHAR(36) NOT NULL,
  `saga_type` VARCHAR(100) NOT NULL,
  `current_step` VARCHAR(100) NOT NULL,
  `status` ENUM('PENDING', 'PROCESSING', 'COMPLETED', 'FAILED', 'COMPENSATING', 'COMPENSATED') NOT NULL,
  `payload` JSON NOT NULL,
  `step_results` JSON NOT NULL,
  `version` INT NOT NULL DEFAULT 1,
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  `updated_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  INDEX `idx_saga_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

NestJS Saga Controller & State Machine Engine

Below is the core implementation of the NestJS Saga Orchestrator. It imports the gRPC client, interacts with MySQL using Knex or typeORM (abstracted here for clarity), and implements the state machine using TypeScript decorators to define saga transitions.

import { Controller, OnModuleInit, Inject } from '@nestjs/common';
import { ClientGrpc } from '@nestjs/microservices';
import { lastValueFrom } from 'rxjs';
import { DataSource } from 'typeorm';

interface ProcessStepRequest {
  sagaId: string;
  stepName: string;
  payload: Buffer;
  executionAttempt: number;
}

interface ProcessStepResponse {
  success: boolean;
  errorMessage: string;
  resultData: Buffer;
}

interface SagaCoordinatorClient {
  processStep(request: ProcessStepRequest): Promise<ProcessStepResponse>;
  compensateStep(request: any): Promise<any>;
}

@Controller()
export class SagaOrchestrator implements OnModuleInit {
  private goWorkerClient: SagaCoordinatorClient;

  constructor(
    @Inject('SAGA_GO_PACKAGE') private readonly client: ClientGrpc,
    private readonly dataSource: DataSource,
  ) {}

  onModuleInit() {
    this.goWorkerClient = this.client.getService<SagaCoordinatorClient>('SagaCoordinator');
  }

  async executeSaga(sagaId: string, steps: string[], payload: any): Promise<boolean> {
    const queryRunner = this.dataSource.createQueryRunner();
    await queryRunner.connect();
    await queryRunner.startTransaction();

    try {
      // Pessimistic write lock to prevent state collision
      const sagaRecord = await queryRunner.manager
        .createQueryBuilder()
        .select('saga')
        .from('saga_logs', 'saga')
        .where('saga.id = :id', { id: sagaId })
        .setLock('pessimistic_write')
        .getOne();

      if (!sagaRecord || sagaRecord.status === 'COMPLETED' || sagaRecord.status === 'FAILED') {
        await queryRunner.rollbackTransaction();
        return false;
      }

      sagaRecord.status = 'PROCESSING';
      await queryRunner.manager.save(sagaRecord);
      await queryRunner.commitTransaction();
    } catch (err) {
      await queryRunner.rollbackTransaction();
      throw err;
    } finally {
      await queryRunner.release();
    }

    // Execute saga steps sequentially
    for (const step of steps) {
      const stepSuccess = await this.executeStepWithRetry(sagaId, step, payload, 3);
      if (!stepSuccess) {
        await this.triggerCompensations(sagaId, steps, step);
        return false;
      }
    }

    await this.updateSagaStatus(sagaId, 'COMPLETED');
    return true;
  }

  private async executeStepWithRetry(
    sagaId: string,
    step: string,
    payload: any,
    maxRetries: number,
  ): Promise<boolean> {
    let attempt = 1;
    while (attempt <= maxRetries) {
      try {
        const response = await this.goWorkerClient.processStep({
          sagaId,
          stepName: step,
          payload: Buffer.from(JSON.stringify(payload)),
          executionAttempt: attempt,
        });

        if (response.success) {
          await this.logStepResult(sagaId, step, 'SUCCESS', response.resultData);
          return true;
        }
      } catch (error) {
        // Exponential backoff logic
        const delay = Math.pow(2, attempt) * 100;
        await new Promise((resolve) => setTimeout(resolve, delay));
      }
      attempt++;
    }
    return false;
  }

  private async logStepResult(sagaId: string, step: string, status: string, resultData: Buffer) {
    await this.dataSource.query(
      `UPDATE saga_logs 
       SET step_results = JSON_SET(step_results, '$.'?, ?),
           current_step = ?
       WHERE id = ?`,
      [step, resultData.toString('utf-8'), step, sagaId],
    );
  }

  private async updateSagaStatus(sagaId: string, status: string) {
    await this.dataSource.query('UPDATE saga_logs SET status = ? WHERE id = ?', [status, sagaId]);
  }

  private async triggerCompensations(sagaId: string, steps: string[], failedStep: string) {
    // Implement rollback flow defined in section 6
  }
}

5. Implementing the Go gRPC Worker Service

Go handles high-throughput operations in this architecture. Go workers process specific commands routed by the orchestrator and execute native local database transactions.

To achieve high-performance transactional safety without using complex ORMs, we write directly to the database via standard library database/sql transactions. The worker ensures that local operations succeed before updating the global saga state.

package main

import (
	"context"
	"database/sql"
	"encoding/json"
	"errors"
	"log"
	"net"

	_ "github.com/go-sql-driver/mysql"
	"google.golang.org/grpc"
	pb "github.com/staksoft/saga/v1/sagav1"
)

type WorkerServer struct {
	pb.UnimplementedSagaCoordinatorServer
	Db *sql.DB
}

type InventoryPayload struct {
	ProductID string `json:"product_id"`
	Quantity  int    `json:"quantity"`
}

func (s *WorkerServer) ProcessStep(ctx context.Context, req *pb.ProcessStepRequest) (*pb.ProcessStepResponse, error) {
	if req.StepName == "ReserveInventory" {
		var payload InventoryPayload
		err := json.Unmarshal(req.Payload, &payload)
		if err != nil {
			return &pb.ProcessStepResponse{Success: false, ErrorMessage: "Invalid payload schema"}, nil
		}

		// Execute local atomic database transaction
		tx, err := s.Db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})
		if err != nil {
			return nil, err
		}
		defer tx.Rollback()

		// Pessimistic lock on inventory to prevent oversells
		var stock int
		err = tx.QueryRowContext(ctx, "SELECT stock FROM products WHERE id = ? FOR UPDATE", payload.ProductID).Scan(&stock)
		if err != nil {
			if errors.Is(err, sql.ErrNoRows) {
				return &pb.ProcessStepResponse{Success: false, ErrorMessage: "Product not found"}, nil
			}
			return nil, err
		}

		if stock < payload.Quantity {
			return &pb.ProcessStepResponse{Success: false, ErrorMessage: "Insufficient inventory stock"}, nil
		}

		_, err = tx.ExecContext(ctx, "UPDATE products SET stock = stock - ? WHERE id = ?", payload.Quantity, payload.ProductID)
		if err != nil {
			return nil, err
		}

		resultBytes, _ := json.Marshal(map[string]string{"status": "allocated"})

		if err := tx.Commit(); err != nil {
			return nil, err
		}

		return &pb.ProcessStepResponse{
			Success:     true,
			ResultData:  resultBytes,
		}, nil
	}

	return &pb.ProcessStepResponse{Success: false, ErrorMessage: "Unsupported step execution"}, nil
}

func (s *WorkerServer) CompensateStep(ctx context.Context, req *pb.CompensateStepRequest) (*pb.CompensateStepResponse, error) {
	if req.StepName == "ReserveInventory" {
		var payload InventoryPayload
		_ = json.Unmarshal(req.Payload, &payload)

		tx, err := s.Db.BeginTx(ctx, nil)
		if err != nil {
			return nil, err
		}
		defer tx.Rollback()

		// Restore reserved stock inventory
		_, err = tx.ExecContext(ctx, "UPDATE products SET stock = stock + ? WHERE id = ?", payload.Quantity, payload.ProductID)
		if err != nil {
			return nil, err
		}

		if err := tx.Commit(); err != nil {
			return nil, err
		}

		return &pb.CompensateStepResponse{Success: true}, nil
	}

	return &pb.CompensateStepResponse{Success: false, ErrorMessage: "Unsupported compensation step"}, nil
}

func main() {
	db, err := sql.Open("mysql", "root:root_pass@tcp(127.0.0.1:3306)/inventory_db")
	if err != nil {
		log.Fatalf("Failed to connect to database: %v", err)
	}
	defer db.Close()

	listener, err := net.Listen("tcp", ":50051")
	if err != nil {
		log.Fatalf("Failed to listen port: %v", err)
	}

	grpcServer := grpc.NewServer()
	pb.RegisterSagaCoordinatorServer(grpcServer, &WorkerServer{Db: db})

	log.Println("Go gRPC Worker running on port :50051...")
	if err := grpcServer.Serve(listener); err != nil {
		log.Fatalf("Failed to serve: %v", err)
	}
}

6. Failure Recovery and Compensating Transactions (Rollbacks)

In distributed saga microservices, steps cannot simply be undone by throwing a transaction exception. If Step 1 (Reserve Inventory) and Step 2 (Charge Card) succeed, but Step 3 (Ship Order) fails, the system must trigger compensating transactions in reverse order: refund the card (Compensate Step 2) and release the inventory (Compensate Step 1).

Compensations must be idempotent. Due to network failures, the orchestrator may execute a compensating action multiple times. If a network packet is dropped after the worker processes a compensation, the orchestrator will retry. Go workers must enforce idempotency keys to ensure that a second execution has no effect and returns success immediately.

Below is the rollback implementation within the NestJS orchestrator. It traverses completed steps in reverse order and executes their compensating endpoints.

// Appended to NestJS SagaOrchestrator class
async triggerCompensations(sagaId: string, steps: string[], failedStep: string): Promise<void> {
  await this.updateSagaStatus(sagaId, 'COMPENSATING');

  // Find index of the failed step
  const failedIndex = steps.indexOf(failedStep);
  if (failedIndex === -1) return;

  // Get all steps completed before the failed step, reversed
  const stepsToCompensate = steps.slice(0, failedIndex).reverse();

  for (const step of stepsToCompensate) {
    let compensationSuccess = false;
    let attempts = 0;
    const maxAttempts = 5;

    while (!compensationSuccess && attempts < maxAttempts) {
      try {
        // Fetch preserved transaction payload from db
        const [saga] = await this.dataSource.query('SELECT payload FROM saga_logs WHERE id = ?', [sagaId]);
        const payload = JSON.parse(saga.payload);

        const response = await this.goWorkerClient.compensateStep({
          sagaId,
          stepName: step,
          payload: Buffer.from(JSON.stringify(payload)),
        });

        if (response.success) {
          compensationSuccess = true;
          await this.dataSource.query(
            `UPDATE saga_logs 
             SET step_results = JSON_SET(step_results, '$.'?, 'COMPENSATED') 
             WHERE id = ?`,
            [`compensate_${step}`, sagaId],
          );
        }
      } catch (error) {
        // Exponential backoff with jitter to protect downstream systems
        const delay = Math.pow(2, attempts) * 150 + Math.random() * 50;
        await new Promise((resolve) => setTimeout(resolve, delay));
      }
      attempts++;
    }

    if (!compensationSuccess) {
      // Critical error: System requires human intervention
      await this.logCriticalError(sagaId, step);
      await this.updateSagaStatus(sagaId, 'FAILED');
      return;
    }
  }

  await this.updateSagaStatus(sagaId, 'COMPENSATED');
}

private async logCriticalError(sagaId: string, step: string) {
  console.error(`FATAL: Compensation failed for saga ${sagaId} at step ${step}. Human intervention required.`);
  // Integrate with system alerting (PagerDuty, Datadog)
}

7. Performance Benchmarking & Observability

Choosing gRPC over HTTP/1.1 REST provides significant performance improvements. Under testing, gRPC maintains sub-millisecond network latency overhead, while REST with JSON serialization suffers from transport layer degradation under high load.

gRPC vs HTTP/JSON Latency & Throughput Benchmark

These benchmarks represent a local development container configuration under a load of 10,000 concurrent requests.

Distributed Tracing with OpenTelemetry

Because sagas span multiple microservices, standard logging is insufficient to debug issues. We use OpenTelemetry (OTel) to inject tracing contexts across gRPC transport barriers. The NestJS orchestrator injects its span context into the gRPC metadata block, which the Go worker extracts to correlate logs under a unified traceId.

In the NestJS Orchestrator, we propagate the context via Metadata:

import { Metadata } from '@grpc/grpc-js';
import { api, propagation } from '@opentelemetry/api';

const metadata = new Metadata();
propagation.inject(api.context.active(), metadata, {
  set: (carrier, key, val) => carrier.set(key, val),
});
// Pass metadata object to goWorkerClient.processStep(req, metadata);

In the Go worker, extract the metadata context:

import (
	"google.golang.org/grpc/metadata"
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/propagation"
)

func (s *WorkerServer) ProcessStep(ctx context.Context, req *pb.ProcessStepRequest) (*pb.ProcessStepResponse, error) {
	md, ok := metadata.FromIncomingContext(ctx)
	if ok {
		propagator := otel.GetTextMapPropagator()
		ctx = propagator.Extract(ctx, propagation.HeaderCarrier(md))
	}
	ctx, span := otel.Tracer("saga-worker").Start(ctx, "ProcessStep:" + req.StepName)
	defer span.End()
	// Core execution continues...
}

8. Security and Production Best Practices

Deploying distributed sagas in production requires strict adherence to network security, system containment, and failure path testing. Implement these key practices to safeguard your services:

• Mutual TLS (mTLS): Enforce mTLS for all gRPC communication. This ensures that only authorized internal microservices can communicate with Go worker processes, protecting endpoints from external intrusion or spoofing.

• Idempotency Validation Layer: Always store processed saga_ids in the downstream services using atomic index constraints (e.g., a unique constraint on saga_id and step_name) to prevent duplicate execution of identical payloads.

• Connection Pooling & Resource Management: Configure database pool limitations properly to prevent sudden spikes in orchestrator retries from exhausting database connection capacities. Systems experiencing high load can encounter connection exhaustion, much like native boundary bottlenecks outlined in our guide on page alignment migration issues. Keep connections bounded.

• Poison Pill Handling: If a particular step payload is structured incorrectly or has an invalid format, retries will fail indefinitely. Configure a Maximum Retry Threshold after which the saga transitions to the FAILED state and triggers an alert. This prevents infinite retry loops from consuming queue and database resources.

9. FAQ Section

How does the Saga Pattern compare to Two-Phase Commit (2PC)?

The Two-Phase Commit (2PC) pattern is a blocking protocol where a coordinator locks database rows across multiple services until all services approve the write. This causes serious latency and deadlocking risk in modern distributed systems. The Saga Pattern, by contrast, operates as a sequence of independent local transactions. It never locks database rows globally, achieving higher availability and system performance while relying on compensating actions to recover from failures.

What happens if the Saga Orchestrator crashes?

Because the Saga Orchestrator persistently logs every state transition in the saga_logs table in MySQL, a crash does not cause data loss. Upon container reboot, a startup cron job query reads all records with PROCESSING or COMPENSATING statuses and restarts the execution engine from the last recorded checkpoint.

Can we use gRPC Streaming for Saga execution?

While gRPC bidirectional streaming is effective for long-lived, reactive connections, unary gRPC is preferred for sagas. Unary gRPC calls map directly to single step execution transitions, making tracking, error handling, and timeout limits simple to configure.

How do we handle out-of-order compensation calls?

In rare scenarios, a network glitch can cause a compensation call to arrive at a microservice before the original execution request. To handle this, write compensation logic defensively: if a compensation request is received for a transaction that has not been executed yet, log the saga_id in a local database table as "pre-compensated." When the actual execution request eventually arrives, check this table first and skip execution if the ID is logged.

10. Summary

Building consistent distributed saga microservices requires transitioning from standard, fragile HTTP/JSON API patterns to contract-driven gRPC engines. Combining NestJS as a state coordinator with Go as a high-performance execution worker provides a resilient foundation for distributed systems. Implementing persistent state logging, strict step retries, and defensive compensating transactions ensures system consistency and reliability under heavy production loads.

Code Snapshots

gRPC Protobuf Contract

syntax = "proto3";

package saga.v1;

option go_package = "github.com/staksoft/saga/v1;sagav1";

service SagaCoordinator {
  rpc ProcessStep (ProcessStepRequest) returns (ProcessStepResponse);
  rpc CompensateStep (CompensateStepRequest) returns (CompensateStepResponse);
}

message ProcessStepRequest {
  string saga_id = 1;
  string step_name = 2;
  bytes payload = 3;
  int32 execution_attempt = 4;
}

message ProcessStepResponse {
  bool success = 1;
  string error_message = 2;
  bytes result_data = 3;
}

message CompensateStepRequest {
  string saga_id = 1;
  string step_name = 2;
  bytes payload = 3;
}

message CompensateStepResponse {
  bool success = 1;
  string error_message = 2;
}

NestJS Saga Orchestrator

import { Controller, OnModuleInit, Inject } from '@nestjs/common';
import { ClientGrpc } from '@nestjs/microservices';
import { lastValueFrom } from 'rxjs';
import { DataSource } from 'typeorm';

interface ProcessStepRequest {
  sagaId: string;
  stepName: string;
  payload: Buffer;
  executionAttempt: number;
}

interface ProcessStepResponse {
  success: boolean;
  errorMessage: string;
  resultData: Buffer;
}

interface SagaCoordinatorClient {
  processStep(request: ProcessStepRequest): Promise;
  compensateStep(request: any): Promise;
}

@Controller()
export class SagaOrchestrator implements OnModuleInit {
  private goWorkerClient: SagaCoordinatorClient;

  constructor(
    @Inject('SAGA_GO_PACKAGE') private readonly client: ClientGrpc,
    private readonly dataSource: DataSource,
  ) {}

  onModuleInit() {
    this.goWorkerClient = this.client.getService('SagaCoordinator');
  }

  async executeSaga(sagaId: string, steps: string[], payload: any): Promise {
    const queryRunner = this.dataSource.createQueryRunner();
    await queryRunner.connect();
    await queryRunner.startTransaction();

    try {
      const sagaRecord = await queryRunner.manager
        .createQueryBuilder()
        .select('saga')
        .from('saga_logs', 'saga')
        .where('saga.id = :id', { id: sagaId })
        .setLock('pessimistic_write')
        .getOne();

      if (!sagaRecord || sagaRecord.status === 'COMPLETED' || sagaRecord.status === 'FAILED') {
        await queryRunner.rollbackTransaction();
        return false;
      }

      sagaRecord.status = 'PROCESSING';
      await queryRunner.manager.save(sagaRecord);
      await queryRunner.commitTransaction();
    } catch (err) {
      await queryRunner.rollbackTransaction();
      throw err;
    } finally {
      await queryRunner.release();
    }

    for (const step of steps) {
      const stepSuccess = await this.executeStepWithRetry(sagaId, step, payload, 3);
      if (!stepSuccess) {
        await this.triggerCompensations(sagaId, steps, step);
        return false;
      }
    }

    await this.updateSagaStatus(sagaId, 'COMPLETED');
    return true;
  }

  private async executeStepWithRetry(
    sagaId: string,
    step: string,
    payload: any,
    maxRetries: number,
  ): Promise {
    let attempt = 1;
    while (attempt <= maxRetries) {
      try {
        const response = await this.goWorkerClient.processStep({
          sagaId,
          stepName: step,
          payload: Buffer.from(JSON.stringify(payload)),
          executionAttempt: attempt,
        });

        if (response.success) {
          await this.logStepResult(sagaId, step, 'SUCCESS', response.resultData);
          return true;
        }
      } catch (error) {
        const delay = Math.pow(2, attempt) * 100;
        await new Promise((resolve) => setTimeout(resolve, delay));
      }
      attempt++;
    }
    return false;
  }

  private async logStepResult(sagaId: string, step: string, status: string, resultData: Buffer) {
    await this.dataSource.query(
      `UPDATE saga_logs 
       SET step_results = JSON_SET(step_results, '$.'?, ?),
           current_step = ?
       WHERE id = ?`,
      [step, resultData.toString('utf-8'), step, sagaId],
    );
  }

  private async updateSagaStatus(sagaId: string, status: string) {
    await this.dataSource.query('UPDATE saga_logs SET status = ? WHERE id = ?', [status, sagaId]);
  }

  private async triggerCompensations(sagaId: string, steps: string[], failedStep: string) {
    // Compensation execution logic
  }
}

Relevant Content Suggestions

• Mitigating WooCommerce Checkout Bottlenecks: MySQL & AJAX Optimization: Explores deep MySQL query locks and database transactional bottleneck reduction, highlighting lock contention prevention mechanics.

• Architecting a High-Performance Shopify MySQL Sync Engine: Demonstrates high-throughput microservice synchronization algorithms utilizing custom TypeScript and Node.js optimization styles.