CQRS and Event Sourcing in Rust: Architecture for Uncompromising Performance

Why CQRS and Event Sourcing Are Not "Overkill" but a Lifesaver for Complex Systems

Have you ever encountered a situation where your system, written in Rust, perfectly handles read requests but "falls to its knees" on writes? Or vice versa — you sacrifice read performance for the ability to save a complete history of changes? Sound familiar? Then welcome to the world of CQRS and Event Sourcing.

Many developers consider these patterns "heavy artillery," applicable only in enterprise projects on C# or Java. But with the growing popularity of Rust in high-load systems (from game servers to financial platforms), CQRS and Event Sourcing are becoming not just useful — they are becoming necessary. Rust, with its zero-cost abstractions and strict typing, is the ideal language for implementing these patterns.

In this article, we won't just talk about theory. We will write working Rust code that you can adapt for your projects. You will learn how to separate responsibilities between commands and queries, how to store events instead of current state, and how all of this speeds up your system many times over.

What Are CQRS and Event Sourcing? In Simple Terms for a Rust Developer

Imagine you are managing a bank account. In a traditional CRUD model, you have one "Accounts" table that stores the current balance. If you need to view the history, you create another "Transactions" table. But what if you need not just to know the balance, but to understand why it changed? Or to restore the state as of any date?

CQRS: Divide and Conquer

CQRS (Command Query Responsibility Segregation) is a principle that divides operations into two groups:

\n
• Commands — change state. They do not return data, only confirmation or an error.
\n
• Queries — only read data. They do not change state.
\n

In Rust, this separation feels natural: command and query types are different structs, and their handlers are different functions or modules. This is not just a "good practice," it's a way to avoid accidental mutations during reads.

// Command — changes state\npub struct CreateOrder {\n    pub user_id: Uuid,\n    pub items: Vec<OrderItem>,\n}\n\n// Query — only reads\npub struct GetOrderHistory {\n    pub user_id: Uuid,\n    pub limit: usize,\n}

Event Sourcing: Store the History, Not a Snapshot

Event Sourcing is an approach where we save not the current state of an object, but the sequence of events that led to it. Want to know the account balance as of January 1, 2023? Just "replay" all events from the beginning to that date.

The advantages are obvious:

\n
• Audit — every change is recorded.
\n
• Time slices — any state can be restored.
\n
• Resilience to bugs — if there is an error in the code, you haven't lost data, you've just replayed it incorrectly.
\n

Practical Example: Order Management System in Rust

Let's build a mini-system for an online store. It will handle commands (creating an order, adding an item) and queries (getting the cart, order history). All logic will be built on events.

Step 1: Define Events and Commands

The first thing to do is design the domain. In Rust, we use enumerations (enum) for events and strict structs for commands.

use serde::{Deserialize, Serialize};\nuse uuid::Uuid;\n\n// Events — immutable facts\n#[derive(Debug, Clone, Serialize, Deserialize)]\npub enum OrderEvent {\n    Created { order_id: Uuid, user_id: Uuid, timestamp: i64 },\n    ItemAdded { order_id: Uuid, item: Str