CQRS (Command Query Responsibility Segregation)
Related service Custom software · everything else
DEFINITION
Separate the write model (commands) from the read model (queries) · often separate schemas, stores, and code paths. Worth it when reads and writes differ wildly in volume, shape, or consistency need. Frequently paired with event sourcing (commands emit events, read models are projections). The cost is eventual consistency between the two sides · the buyer needs to be told.
- Docker→
We package an app with its dependencies into an image, which runs as a container - identical on your laptop and in production. "Works on my machine" stops being an excuse.
- CI/CD→
Continuous Integration / Delivery: every commit is automatically built, tested and (optionally) deployed. This pipeline lets us ship safely many times a day, without manual mistakes.
- Blue-Green Deployment→
We run two identical environments: blue is live, green is the new version. Once green is verified we flip traffic to it; on trouble we flip back instantly. Zero-downtime releases with instant rollback.
- Horizontal Scaling→
We add more machines/instances (scale out) instead of one bigger box (vertical, scale up). For stateless services this wins: cheaper, more elastic, no ceiling. State goes to a separate store.
- Load Balancer→
Distributes incoming traffic across multiple instances - the front door that gives you redundancy and smooth scaling. Health checks remove dead instances, so one failure stays invisible to users.
- Distributed Tracing→
We follow one request across every service using a trace ID (e.g. OpenTelemetry). In a microservices system this is how we pinpoint which service slowed down or failed - no guessing.