Golang Microservices Full Course #28 - SAGA Pattern Introduction - Transaction Service

Summary

The video extracts the transaction module into a standalone Transaction Service, following the earlier creation of a Ledger Service. The new service has its own database and transaction table, including idempotency-key validation. It exposes the existing transaction operations—top-up, transfer, and transaction history—and coordinates with other services through gRPC, including the Wallet and Ledger services.

Implementation and setup

• Adds the service’s main entry point and handler, model, repository, and service layers.
• Adds a database migration for the transaction table and configures the service and its port in Docker Compose.
• Builds service binaries on the host with a Makefile and copies them into Docker images. The presenter describes this as a workaround for high Docker build memory usage on their 8 GB machine.
• Tests a transfer between users: the sender’s wallet balance changes as expected, and the ledger reconciliation check reports consistency.

Saga pattern and transaction flow

A conventional database transaction—with begin, commit, and rollback—cannot make changes atomic across separate Wallet, Ledger, and Transaction databases. The video introduces the Saga pattern, which coordinates a distributed transaction through smaller, service-local transactions.

Two Saga styles are described:

• Choreography: Services coordinate by publishing and listening for events. This suits simpler workflows.
• Orchestration: A central coordinator directs the participating services and manages the workflow.

The Transaction Service is implemented as an orchestrator using synchronous gRPC calls. The transfer flow is:

1. Check the idempotency key.
2. Create a transaction record with pending status.
3. Debit the sender’s wallet.
4. Credit the receiver’s wallet.
5. Record the corresponding debit and credit ledger entries.
6. Mark the transaction successful if all steps complete, or failed if an error occurs.

Because these steps affect different databases, a partial failure can leave an inconsistent result—for example, the sender may be debited even if crediting the receiver fails. A Saga addresses this with a compensating transaction, such as returning the sender’s funds and recording the appropriate ledger entries.

The video describes compensation as a necessary future step; it is not yet implemented in the shown flow. For now, the service waits for downstream operations to finish before responding. The presenter notes that a production flow could instead return a pending response and update the outcome later.

Main speaker

Ikhda Muhammad Wildani, the course presenter and sole speaker.