Lifecycle of a BigchainDB Transaction

A step-by-step overview.

Some of the recent queries from our customers and community members have been around how a transaction is created and committed in BigchainDB 2.0. We created a sequence diagram showing the entire lifecycle of a transaction. Here it is.

BigchainDB Transaction Lifecycle — Sequence Diagram

The following steps define the stages in the lifecycle of a BigchainDB transaction. (The steps are numbered according to the numbers with the connectors in the sequence diagram above.)

Client Side

1. The app passes the JSON data and the signing key-pair to the BigchainDB driver. The BigchainDB driver is included in the client app as a library or module.
2. The BigchainDB driver prepares the transaction encapsulating the JSON data and signs it using the private key in the key-pair.
3. The BigchainDB driver then POSTs the transaction to the BigchainDB node (server) using the HTTP API provided by BigchainDB server.

Server Side

On the server side, a BigchainDB node is comprised of three components — BigchainDB server, Tendermint and MongoDB.

1. After receiving the transaction from the client app, the BigchainDB server component performs some initial validations on it.
2. The BigchainDB server component then POSTs the transaction to the tendermint component. The transaction is received in the Tendermint memory pool.
   Note: If the transaction is posted in async mode, response is returned after this step. The process continues.
3. The BigchainDB server component performs some additional validations on the transaction.
   Note: If the transaction is posted in sync mode, response is returned after this step. The process continues.
4. After all validations, the Tendermint component performs consensus process. As part of this process the transactions in memory pool are packaged into a block and all nodes vote on the validity of the block.
   Note: This is a very simplified description of the consensus process. For details, see Tendermint documentation.
5. Once a consensus is reached among all the Tendermint components (nodes) of all BigchainDB nodes, then the Tendermint component of each node sends a request to the BigchainDB server component to commit the block.
6. The BigchainDB server component then commits the block of transactions in MongoDB and sends a response back to the Tendermint component indicating the completion of block commit.
7. The BigchainDB server then sends the response back to the app (and driver) that the transaction has been committed in a block. This also completes the lifecycle of a transaction.
   Note: If the transaction is posted in commit mode, response is returned in this step.

Note: This is a high-level overview of transaction lifecycle for basic understanding of how BigchainDB works. A more detailed overview of the entire transaction creation and commit process is available in our whitepaper. If you are looking for more technical details, we recommend going through our documentation.

The sequence diagram is co-created with Manuel Rodríguez Franco.

Thanks to Lev Berman, Vanshdeep Singh, Troy McConaghy and vrde for their feedback.

Follow us on Twitter and LinkedIn to get the latest announcements. Visit our website to learn more about us and to Get Started using BigchainDB software today. Ask any technical questions you may have to our developers on Gitter. If you’re a developer using BigchainDB, we want to hear from you. Send us an email at contact@bigchaindb.com and tell us your story.