Announcing Transaction Orchestrator

The Need for Improved Transaction and Workflow Management

1. Data consistency: In a distributed system, maintaining data consistency across different databases becomes challenging. A TO ensures that if any part of the transaction fails, all the previous steps are rolled back (compensated), keeping the data consistent across all involved databases.
2. Coordination: Acting as a coordinator between different modules and their respective servers, the TO manages the order of execution and communication between modules, ensuring that each transaction step is executed correctly and at the right time.
3. Simplifying complex workflows: In a distributed environment, transactions can become complex due to the need to coordinate between different services and databases. A TO simplifies this process by abstracting away the complexities of managing distributed transactions, allowing developers to focus on implementing the business logic.
4. Scalability: As a system grows, managing transactions across multiple services becomes increasingly difficult. A TO helps with scalability by providing a robust framework for managing distributed transactions, making it easier to maintain and expand the system.

• Composable architectures: A transaction orchestrator supports composable architectures, allowing developers to easily combine and reuse modules as needed. This enables the creation of highly customizable commerce applications, tailored to specific business requirements.
• Adoption in legacy systems: The TO can also facilitate the gradual transition of legacy systems to more modern, distributed architectures. This makes it easier for businesses to adopt and integrate new technologies without having to rebuild their entire infrastructure from scratch.
• Unlocking infrastructure technologies: With a transaction orchestrator, developers can leverage advanced infrastructure technologies, such as serverless and edge computing. This can lead to improved performance, reduced latency, and increased reliability for commerce applications, resulting in better user experiences and higher customer satisfaction.

123456789
Module A creates an order (Server 1, Database 1)
Module B manages inventory (Server 2, Database 2)
Module C handles payments (Server 3, Database 3)

A typical transaction flow would be:

1. Create order in Module A
2. Deduct inventory in Module B
3. Process payment in Module C

Achieving Cleaner Code with the Transaction Orchestrator

1. Abstraction: A TO abstracts the complexity of managing distributed transactions by providing a standardized framework for defining transaction steps, their corresponding compensation actions, and the flow of execution. This allows developers to focus on implementing the core business logic of each step rather than managing the complexities of distributed transactions.
2. Separation of concerns: By clearly delineating the responsibilities of each function, the TO enforces the separation of concerns. Each function is responsible for either the "Invoke" (execution) or "Compensate" (rollback) action, ensuring they perform a single, specific task. This makes the code more readable, maintainable, and testable.
3. Modularity: By using a TO, the code becomes more modular as each step in the transaction is encapsulated within its own function. This allows developers to easily modify, add, or remove transaction steps without affecting the overall structure of the transaction.
4. Error Handling: When handling distributed transactions manually, the code can become convoluted due to intricate error handling logic. The TO simplifies this by automatically managing errors and retries, allowing developers to create cleaner code without the need to address error handling for each step.
5. Reusability: The TO allows you to define reusable functions for both the "Invoke" and "Compensate" actions, which can be easily reused across different transaction scenarios. This reduces code duplication and ensures that changes to a specific action only need to be made in one place.

1234567891011121314
const createVariantFlow: TransactionStepsDefinition = {
    next: {
        action: "createVariantStep",
        saveResponse: true,
        next: {
            action: "createInventoryItemStep",
            saveResponse: true,
            next: {
                action: "attachInventoryItemStep",
                noCompensation: true,
            },
        },
    },
}

12345678910111213141516171819202122232425262728293031323334
async function transactionHandler(
    actionId: string,
    type: TransactionHandlerType,
    payload: TransactionPayload
) {
    const command = {
        createVariantStep: {
            invoke: async (data: CreateProductVariantInput) => {
                return await createProductVariant(data) // omitted
            },
            compensate: async (data: CreateProductVariantInput, { invoke }) => {
                await removeProductVariant(invoke.createVariantStep) // omitted
            },
        },
        createInventoryItemStep: {
            invoke: async (data: CreateProductVariantInput, { invoke }) => {
                return await createInventoryItem(invoke.createVariantStep) // omitted
            },
            compensate: async (data: CreateProductVariantInput, { invoke }) => {
                await removeInventoryItem(invoke.createInventoryItemStep) // omitted
            },
        },
        attachInventoryItemStep: {
            invoke: async (data: CreateProductVariantInput, { invoke }) => {
                return await attachInventoryItem( // omitted
                    invoke.createVariantStep,
                    invoke.createInventoryItemStep
                )
            },
        },
    }

    return command[actionId][type](payload.data, payload.context)
}

1234567891011
const strategy = new TransactionOrchestrator(
    "create-variant-with-inventory", // transaction name
    createVariantFlow // transaction steps definition
)

const transaction = await strategy.beginTransaction(
    ulid(), // unique id
    transactionHandler, // handler
    createProductVariantInput // input
)
await strategy.resume(transaction)

Handling Complex Workflows with the Transaction Orchestrator

1. E-commerce order fulfillment: In an e-commerce system, a workflow might involve creating an order, reserving inventory, charging the customer, generating shipping labels, and updating the shipping status. Some of these steps, such as generating shipping labels or charging the customer, could take a considerable amount of time due to external dependencies like payment gateways and shipping services.
2. Fraud detection and prevention: In an e-commerce system, fraud detection and prevention workflows might involve analyzing customer data, order patterns, and payment information to identify potential fraudulent activities. These workflows may include time-consuming tasks like querying external fraud detection APIs or applying machine learning models to analyze data.
3. Returns and refunds processing: In an e-commerce returns and refunds workflow, several steps may involve long-running tasks, such as receiving returned products, inspecting their condition, updating inventory, and processing refunds. Some of these steps may take a considerable amount of time, especially when dealing with external payment gateways or waiting for products to be returned and inspected.

What’s Next