Home
Welcome to the chain index service wiki! You will find an overview of the project, research and discussions, and the details of the design decision behind.
Chain index service indexes the Crypto.com Chain states into the database for fast local retrieval. It highly facilitates the process of end-user applications, such as wallets and explorers, getting the historical and latest data from the chain.
What is event sourcing & why needs it?
Event sourcing is a software architecture pattern which ensures that all changes to the application state are stored as a sequence of events. Comparing with CRUD, event sourcing can preserve the whole past states while CRUD is always storing and patching to the latest states. Therefore, we can not just query these events, but also use the events to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.
The main reasons that event sourcing pattern will benefit the chain index service a lot are,
- Blockchain data is naturally a sequence of events, such as block data with incremental block height, transactions inside the blocks, etc.
- Index service is a typical application that has lots of readers and a few writers, the event sourcing pattern can provide excellent horizontal scalability such as deliver a cluster of read-only databases or in-memory caches to serve flooding reading requests.
- Since all events are preserved, by creating database views based on the events, it can provide a much more flexible data model for new data fields (E.g. as calculating the
uptimefor a validator based on historical data). - No more migration scripts and re-index from the genesis block, as long as the events are defined properly and completely.
How about CQRS?
CQRS(Command Query Responsibility Segregation) is actually the pattern that makes event sourcing possible, it separates reading and writing into two different groups as Query and Command. The goal of CQRS is to represent the same data in multiple models and that's it.
All use cases will be segregated into two groups: Commands that change data and Queries that return data. Each use case can be either command or query but never both.
References