Transactions commited to the ledger are fully atomic and serialized, supported by two separate and ordered concurrency-control mechanisms preventing effectively race-conditions to happen:
- Pre-commit in-memory or Redis-based locking
- Optimistic locking
Transaction commit flow
Recommendation for multi-instances deployments
Due to the sequential nature of the ledger, multiple instances deployments should be carefully configured.
We recommended to use the Redis-based shared pre-commit lock using the redis flags. While the optimistic lock will ultimately be there to prevent race-conditions on commit, using the shared lock will reduce such commit attempts in the first place, yielding better performance for write heavy workloads.
Also, you can find a complete docker-compose example using 3 instances of the ledger, and a simple reverse proxy to handle traffic there.
Should the optimistic locking prevent a conflict on commit, it will surface it to the API consumer with a (Response 409) - it is the responsibility of the client to retry the transaction in this case.