CQRS vs CRUD Choosing the Right Pattern for Large-scale Applications

As applications scale, traditional CRUD (Create, Read, Update, Delete) patterns may struggle to handle performance, scalability, and complexity demands. CQRS (Command Query Responsibility Segregation) offers an alternative by separating read and write operations, improving scalability and performance in large-scale applications.

This article explores CRUD vs. CQRS, their differences, and when to use each to design efficient, scalable applications.

CRUD is a simplified data access pattern where the same model is used for reading and writing data in a system.

graph TD;
    User-->API;
    API-->Database[Database];
    Database-->API;
    API-->User;

This pattern is straightforward but has limitations when:

• Read and write operations require different optimizations (e.g., caching for reads, transactions for writes).
• Scaling becomes inefficient due to database locking and contention.
• Complex business logic results in performance bottlenecks.

CQRS (Command Query Responsibility Segregation) separates read and write operations into distinct models.

• Command Model - Handles writes (Create, Update, Delete).
• Query Model - Handles reads (optimized for retrieval).

graph TD;
    User-->Write_API["Write API (Commands)"];
    User-->Read_API["Read API (Queries)"];
    Write_API-->CommandDB["Command Database"];
    CommandDB-->EventBus["Event Bus"];
    EventBus-->ReadDB["Read Database"];
    ReadDB-->Read_API;
    Read_API-->User;

• Simple applications where read and write operations have similar requirements.
• Small-scale projects where complexity overhead is not justified.
• Strong consistency is a priority, and eventual consistency is not acceptable.

• High read/write disparity (e.g., analytics dashboards with frequent reads).
• Scalability requirements, where different databases or caching strategies optimize reads and writes separately.
• Event-driven systems, where changes trigger multiple reactions asynchronously.
• Microservices architecture, enabling services to scale independently.

Let's implement a basic CQRS pattern in Go using Gorilla Mux for API handling.

go mod init cqrs-example
go get github.com/gorilla/mux

package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Order struct {
	ID     string `json:"id"`
	Amount int    `json:"amount"`
}

var orders = make(map[string]Order)

func createOrder(w http.ResponseWriter, r *http.Request) {
	var order Order
	json.NewDecoder(r.Body).Decode(&order)
	orders[order.ID] = order
	log.Println("Order Created:", order.ID)
	w.WriteHeader(http.StatusCreated)
}

func main() {
	router := mux.NewRouter()
	router.HandleFunc("/orders", createOrder).Methods("POST")
	log.Fatal(http.ListenAndServe(":8080", router))
}

package main

import (
	"encoding/json"
	"log"
	"net/http"

	"github.com/gorilla/mux"
)

func getOrder(w http.ResponseWriter, r *http.Request) {
	vars := mux.Vars(r)
	order, exists := orders[vars["id"]]
	if !exists {
		w.WriteHeader(http.StatusNotFound)
		return
	}
	json.NewEncoder(w).Encode(order)
}

func main() {
	router := mux.NewRouter()
	router.HandleFunc("/orders/{id}", getOrder).Methods("GET")
	log.Fatal(http.ListenAndServe(":8081", router))
}

While CQRS offers scalability and performance benefits, it introduces complexity.

• Problem: Read models lag behind write models due to event processing delays.
• Solution: Implement event versioning and idempotency to maintain consistency.

• Problem: Maintaining two separate models increases code complexity.
• Solution: Use event-driven frameworks like Kafka or NATS to manage event propagation efficiently.

Both CQRS and CRUD have their place in software architecture.

• CRUD is simple and ideal for small applications with consistent data access patterns.
• CQRS is powerful for large-scale, high-performance applications where read and write operations have different scaling needs.

Understanding when to apply each pattern ensures that applications remain scalable, efficient, and maintainable as they grow.