He went through those topics:
Scaling writes to the #ledger
DAML Ledgers follow a Command Query Responsibility Segregation (CQRS), event-sourced architecture. This means:
- Writing to the ledger (Command) is a first data flow, a sequence of transactions
- The ledger is a long log of transactions and is the source of truth for all data
- Reading from the ledger (Query) is a second, segregated data flow
- In DAML, all interaction between the write and read path is through the immutable ledger, there are no out-of-bounds workflows.
Which parts are trivial to scale horizontally?
- Serving the API - similar to any API endpoint
- Read path - by duplicating the read stream and creating multiple caches (copies). The ledger is an immutable stream of events, so no synchronization between these is necessary
- Write path - not so trivial because we need to ensure we’re not writing conflicting transactions to the ledger
The write path has to validate three things about the transaction being written to the ledger:
- Conforms to the rules of DAML ← Highest need for computing resources (CPU and memory)
- Is authorized by someone who is allowed to write it
- Doesn’t conflict with any previous transaction
We can now split the write path into two stages, one is horizontally scalable and the other is sequential
Any questions to @Shaul ?