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

# Architecture overview

<figure><img src="/files/ME0WsLmx8xbL70k2Kfo5" alt=""><figcaption></figcaption></figure>

QuantInfra is a distributed event-based platform. The main components are:

* <mark style="color:$warning;">**Critical path**</mark>
  * **Accounts Service** — the main source of information about the state of accounts and strategies. It uses a Write-Ahead-Log to record all incoming events and commands, and can replay them on restart. All outgoing events are distributed to downstream components via multicast and asynchronously persisted into the history database for resilience and reporting. WAL can be copied to a development environment for investigating issues.
  * **Strategies Service** — hosts strategies, hydrates and aggregates market data for them. One Strategies Service can host one or several strategies. Combining several strategies helps reduce the number of required CPU cores, slightly increasing the processing time for a particular strategy.
  * **Execution Service** — hosts trading connectors and communicates with brokers/exchanges. Every Execution Service may serve one or several connectors.
  * **Market data connectors** — connectors to various market data sources
* Other components
  * A centralized history database that persistently keeps all events from different Accounts Services and is used for resilience (restoring account states when a local disk of the server hosting an Accounts Service fails) and for reporting
  * Control panel — an internal web tool used to access and control strategies and accounts
  * Client's reporting — an external web portal for your clients
* Backtesting
  * Backtesting workers running backtests and optimizations may be scaled on demand, spawning across thousands of cores if required

## Scalability

Components on the critical path may be scaled by entity (accounts/strategies/trading connectors/market data connectors) and by location: there may be several clusters deployed close to brokers or exchanges, that will share the reporting and control layer.

## Deployment options

The standard deployment model hosts all components inside a Kubernetes cluster. If your strategies are time-critical, it's recommended to use a single server/VM to host the components on the critical path; in this scenario, the network delays are on average around 250-300us vs 1-2ms when using the cluster network.

For even lower latency, a monolith deployment can be used, in which all components on the critical path run inside a single process and do not use the network at all. It is expected that the total delays introduced by the platform may fall to the double-digit microsecond range in this scenario (20-50us).

Whereas for low latency, it's recommended to use a server with a number of cores exceeding the total number of threads inside the components (5 for AS, 3 for SS, 3 + N connections for ES, 2 + N connections for MDC), the platform works totally fine on a set of discovery VMs (with internal latency staying in a single-digit milliseconds range).

Independently on the chosen deployment model, there is no vendor lock: the platform can be deployed to any public or private cloud or bare metal.


---

# 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, and the optional `goal` query parameter:

```
GET https://quantinfra.gitbook.io/quantinfra-docs/core-concepts/architecture-overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.