github.com/kaleido-io/firefly@v0.0.0-20210622132723-8b4b6aacb971/docs/architecture/multiparty_event_sequencing.md (about) 1 --- 2 layout: default 3 title: Multiparty Event Sequencing 4 parent: Architecture 5 nav_order: 2 6 --- 7 8 # Multiparty Event Sequencing 9 {: .no_toc } 10 11 ## Table of contents 12 {: .no_toc .text-delta } 13 14 1. TOC 15 {:toc} 16 17 --- 18 19  20 21 ## Transaction Submission 22 23 * An individual FireFly instance preserves the order that it received messages from application instances. 24 * Where possible, batching is used to roll-up hundreds of transactions into a single blockchain transaction. 25 * *Blockchain allows these messages to be globally sequenced with messages submitted by other members of the network.* 26 27 ## Blockchain Ordering 28 29 * All member FireFly runtimes see every transaction in the same sequence. 30 * *This includes when transactions are being submitted by both sides concurrently.* 31 32 ## Message Assembly 33 34 * A queue of events is maintained for each matching app subscription. 35 * The public/private payloads travel separately to the blockchain, and arrive at different times. FireFly assembles these together prior to delivery. 36 * If data associated with a blockchain transaction is late, or does not arrive, all messages on the same "context" will be blocked. 37 * *It is good practice to send messages that don't need to be processed in order, with different "context" fields. For example use the ID of your business transaction, or other long-running process / customer identifier.* 38 39 ## Event Processing 40 41 * Events are processed consistently by all parties. 42 * All FireFly runtimes see every event that they are subscribed to, in the same sequence. 43 * *The submitter must also apply the logic only in the sequence ordered by the blockhain. It cannot assume the order even if it is the member that submitted it.*