---
title: "Architecture: one leader per tenant"
description: "A Queen node is one process, and every write is decided once, on the leader of its tenant's raft group, then applied on every node. A transaction is one log entry."
---

> Queen MQ documentation, for AI agents
> Complete self-contained summary of Queen MQ: https://queenmq.com/llms-brief.txt
> Fetch that first when the question is about the product rather than about this page.
> Index of all pages: https://queenmq.com/llms.txt

# Architecture: one leader per tenant

A Queen node is one process. Every write is decided once, on the leader, and then applied on every node. These pages follow a write through the process, from the request to the disk.

The rule behind the whole design is: **one leader per tenant**. A tenant lives in one raft group, and one leader orders all its writes. So a transaction, even across ten queues, is one log entry: no coordinator, no two-phase commit. The price is that one tenant's writes do not spread over more nodes. To use more nodes for writes, run more raft groups (see [Many tenants on one cluster](/manage/configuration/#many-tenants-on-one-cluster)): with as many groups as nodes, every node leads one.

**Figure.** Three nodes, each holding a copy of three raft groups, g0, g1 and g2. Each group has its own log and its own leader: here g0 is led on node 1, g1 on node 2 and g2 on node 3, so every node leads one group. A tenant lives in one group: acme in g0, globex in g1. A transaction of acme across three queues is one entry in g0's log.

One leader per tenant: three raft groups, each led on a different node.

Source: https://queenmq.com/architecture/index.mdx