Introduction
Last updated
Last updated
Blockchain can't defy the laws of physics—higher TPS demands more computational resources. In centralized systems, horizontal scaling is effective, but most blockchain projects use a single-thread, monolithic design (e.g., Geth for Ethereum) limited to one machine and core, hindering support for high-performance applications.
Arcology is a high-performance, general-purpose system that requires a flexible, scalable, and loosely coupled architecture. An ED microservice architecture meets these needs, with key modules provided as independent, easily scalable services.
An event broker is middleware that connects and mediates communication among different modules. It follows a pub/sub model to receive, cache, and route messages to and from handlers. The broker is both inter-thread and inter-process, facilitating communication within the same process and across threads of multiple processes. This design enables cluster deployment, ensuring maximum scalability and flexibility.
Arcology features a specialized event broker known as Streamer, specifically designed to manage internal communications. For more information, please refer to this link.
An event handler is responsible for processing events received from the event broker. In Arcology, all major components, such as the transaction pool, EVM, StateDB, and others, are wrapped as event handlers. In Arcology, modules only communicate asynchronously via the event brokers and operate independently, with minimal awareness of one another. This design effectively decouples the functional modules.
This design improves resource utilization and facilitates intra-node horizontal scaling, which involves adding more instances of the same module to manage increased workloads. In addition, depending on specific needs, an Arcology node can be configured to be either cost-efficient or performance-optimized.
A node is a combination of hardware and client software that function as an independent entity on Arcology network. For all other blockchains, a full node is usually a copy of client software installed on one machine, either physical or virtual.
An Arcology node could also mean a group of machines connected by high-speed networks with multiple instances of functional modules installed. These machines will function just like one.
An Arcology client is the software system that supports the functionality of an Arcology node. It can be installed on a single machine or a cluster of machines, depending on the configuration.
Streamer is an event management system built for Arcology. It's using the pub/sub pattern to work with multiple event handlers. A Streamer instance may also be connected to an inter-Process event broker (like Kafka) to handler event transmission across processes.
Arcology uses Apache Kafka to connect different Streamer instances.
A service is a logical unit of worker threads(event handlers) connected by a Streamer instance. A service can be deployed, operated, and accessed independently.
A worker thread is a functional unit doing a specific job independently of other workers. Worker threads are connected one Streamer instance. A worker acts on a certain combination of events and may also generate some events and send them to the Streamer instance as well.
