Architectural insights
Blnk’s architecture incorporates queuing and optimistic locking to manage concurrency as illustrated below:
Simplified overview of how Blnk manages concurrency
Queuing transactions
The queuing system manages transaction flow through partition-based processing. When transactions enter the system, they are routed to specific queue partitions based on their characteristics. Similar transactions affecting the same balance are grouped in a single partition, ensuring sequential processing order. Key aspects of the queuing system:- Partition Assignment: Incoming transactions are assigned to available partitions. If one partition is busy, new transactions are routed to other free partitions.
- Worker Processing: Worker processes pull transactions from the queue partitions. The number of simultaneously processed transactions depends on available workers.
- Sequential Consistency: Transactions within the same partition are processed sequentially, maintaining order for related operations.
Idempotency in transaction processing
Blnk’s transaction system ensures idempotency through reference value tracking. When multiple instances of the same transaction occur due to network or system errors, the system:- Identifies duplicate transactions using their
reference
value - Processes only one instance of the transaction
- Discards additional duplicate requests
Optimistic locking for conflict resolution
The optimistic locking mechanism complements the queuing system by providing conflict resolution at the data layer. Instead of locking resources preemptively, the system:- Allows transactions to proceed concurrently.
- Performs conflict detection at commit time.
- Checks if data has been modified since the transaction started.
- Rolls back and retries transactions if conflicts are detected.
How optimistic locking works in Blnk
- Version tracking: Each record in the database is associated with a version number. When a transaction reads a record, it notes the version number.
- Update attempt: When the transaction attempts to update the record, it specifies the version number it originally read.
- Conflict detection: If the current version in the database does not match the version number noted by the transaction in #2, a conflict is detected (indicating that another transaction has updated the record). If no conflict is detected, the transaction moves to queue for processing.
- Resolution: Upon conflict detection, the transaction is rolled back. Blnk may automatically retry the transaction, depending on the scenario and the conflict’s nature.