Blockchain-based solutions requires a level of scalability to process thousands or messages with little or no room for delay and downtime. Many traditional programmers focus on linear step-based procedural-event programming that fails when heavy demand occurs at the most critical moment. E-commerce web sites usually fall victim to server crashes during holiday shopping season and on Black Friday due to procedural style of programming. 

A more scalable approach to processing huge volumes of data is a message queue. A message queue architecture is where one application simply drops a message into a queue – no database inserts or waiting for a response. Then another application checks the queue for incoming messages and process it. Message queue approach is more scalable as a web site can just drop a message with little server overhead and another application follow up on the processing. 

A traditional message queue operates on a first-come, first-serve basis. For example, consider a concert ticket service with thousands of people trying to buy tickets at one time.  When the first customer places a request for seat 1A, the web site simply send the request as a message to a queue. If a second person at the same moment request seat 1A, the first request in the queue would be processed and the second order will be cancelled. This technique prevents double-booking the same seat but also create a scalable system to make sure all orders are handled in a smooth sequential matter. 

The issue with a traditional queue system is maintaining two or more applications where one application inserts the message and another message retrieve the message.  Concurrent queue programming operates on a multi-thread basis where one application can handle both dropping messages in a queue and removing messages from a queue at the same time in a concurrent manner. One application program can add messages and process at the same time. 

Examples of concurrent queue programming are multi-player video games where a notification message will state “player A eliminated player B” as a scrolling message on the screen. Another example is a self-checkout grocery station where products are scanned and the screen display the product, price and running total. With the ADOS Digerati, there are more advanced solutions with concurrent queue programming.  For example, a bot can access the blockchain and download messages from a distributed ledger for processing in a concurrent queue fashion. 

Concurrent queue processing is best suited for applications that do not require a sequential order such as post-transaction jobs such as generating a receipt, email and messaging, status notification. A financial ledger such as a debit card or banking account can use concurrent queue programming as the charging coming in do not need to be sequential. 

Concurrent queue processing is not suited for applications that does require sequential programming. A trading marketing exchange order matching engine must process incoming orders on sequential set of rules. Requests for seating tickets also cannot use concurrent processing as seats must be reserved on a first-come, first service basis. 

When developing next-generation applications supporting blockchain technology and message-orientated architecture, the ADOS Digerati has to learn how to create concurrent queue design patterns for scalability and performance.  Concurrent queue programming is an essential technique to drive Fourth Industrial Revolution applications for the ADOS Digerati ecosystem.