Closed WilfredAlmeida closed 7 months ago
The execution order when the system starts will be:
- Fetch the latest processed transaction signature on a tree from the database, let's call it
lastProcessedTxSignature
- Pull transaction signatures from the latest transaction to
lastProcessedTxSignature
from the chain- Pull and process each transaction data
- Initiate the WebSocket listeners for the trees
Suppose:
- The program begins at the time
T1
- Steps 1-3 take 10 seconds and complete at the time
T10
- Step 4 begins at
T11
and listens for transactions on the tree as they happenThe transactions between time
T1-T10
will not be processed and result in an incorrect state in the databaseSolutions:
- Starting both the synchronous processing of transactions and Websocket listeners on trees at the same time
- This won't work as the synchronous processing, and WebSocket listeners will upsert the database together, and the state will be incorrect
- Setup a message queue and worker threads/processes to process transactions
With this approach, the flow will be:
- The main thread starts with both synchronous transaction processing and WebSocket listeners
- Both push their respective transaction signatures into their respective queues, let's call them
synchronousTxsQueue
andwebsocketTxsQueue
- A worker thread picks transaction signatures from these queues and processes them
- The worker thread will have the logic
if synchronousTxsQueue.hasNext() processTransaction(synchronousTxsQueue.deQueue) else processTransaction(websocketTxsQueue.dqQueue)
Suggested Message Queue:
- Kafka: Supports consumer notification, replication, and retries, and can handle scale. Will be future-proof
- Redis: Metaplex DAS already has Redis which is used for data streaming. A similar stream can be added to it
Questions:
- Is approach 2 good enough?
- If yes, which queue is good to use?
Yes, it addresses the main issue of ensuring all transactions are processed in the correct sequence without loss or duplication. It provides a scalable and reliable architecture that can adapt to varying loads and network conditions.
Ideally Kafka is used but if metaplex is already using Redis and it aligns with us, should go with Redis. as Kafka can be complicated sometimes
We've decided to move ahead with an in-memory queue. Please refer to the documentation for more details
The execution order when the system starts will be:
lastProcessedTxSignature
lastProcessedTxSignature
from the chainSuppose:
T1
T10
T11
and listens for transactions on the tree as they happenThe transactions between time
T1-T10
will not be processed and result in an incorrect state in the databaseSolutions:
Starting both the synchronous processing of transactions and Websocket listeners on trees at the same time
Setup a message queue and worker threads/processes to process transactions
With this approach, the flow will be:
synchronousTxsQueue
andwebsocketTxsQueue
Suggested Message Queue:
Questions: