In this lesson, you will learn how to split your application’s data modification logic from its data retrieval logic to help your Node.js services scale more effectively.
The Problem: The "One-Size-Fits-All" Model
In a typical Node.js application, we often use a single model or service to both "write" (change data) and "read" (fetch data). As your system grows, you might find that your write operations are complex—perhaps they trigger side effects, perform validation, or involve long-running asynchronous tasks. Meanwhile, your read operations just need to be fast. If you use the same path for both, the overhead of the "write" logic can slow down your "read" queries, creating a bottleneck.
The Solution: Command Query Responsibility Segregation (CQRS)
CQRS is the architectural pattern of separating these two responsibilities.
- Commands: These represent the "write" side. They are asynchronous operations that change the state of your system (e.g.,
UpdateUserPasswordCommand). - Queries: These represent the "read" side. They are optimized solely for returning data to the user without side effects.
By separating them, you can scale them independently. For example, you might scale your read database replicas for queries, while keeping your write operations on a highly consistent primary node.
A Simple Example
Imagine a command that processes a heavy user update:
// Command: Side-effect heavy, asynchronous, changes state
async function executeUpdateUserCommand(userId, data) {
// Perform validation, trigger events, update DB
await db.users.update(userId, data);
await auditLog.save(`User ${userId} updated`);
}
// Query: Optimized, read-only
async function getUserProfileQuery(userId) {
// Directly fetch from a read-optimized view or cache
return await cache.get(`user_profile:${userId}`);
}
By decoupling these, your getUserProfileQuery doesn't need to know about the audit logging or complex validation logic. It just fetches the data. This keeps your application logic clean and allows you to tune each path for performance without them interfering with one another.
Key Takeaway: By separating Commands from Queries, you isolate your system’s heavy write logic from its read paths, allowing each to be scaled and optimized independently for better performance.