> For the complete documentation index, see [llms.txt](https://docs.arcology.network/arcology-architecture-overview/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcology.network/arcology-architecture-overview/intro.md).

# Introduction

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.

## Architecture

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.

#### **Event Broker**

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.

{% hint style="info" %}
Arcology features a specialized event broker known as Streamer, specifically designed to manage internal communications. For more information, please refer to [this link](https://doc.arcology.network/streamer).
{% endhint %}

#### **Event Handler**

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.

![alt text](/files/xdgZtNvlazsXdE47K21I)

### Benefits

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. 

***

## Terminology

#### Node

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.

#### Node Cluster

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.

#### Client Software

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.

#### Intra-Process Broker (Streamer)

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.

#### Inter-Process Broker (Kafka)

Arcology uses Apache Kafka to connect different Streamer instances.

#### Service

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. 

#### Worker Thread(Event handler)

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.arcology.network/arcology-architecture-overview/intro.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.