Hi, I’m Tuyen

What is CQRS (in one line) Separate the write side (commands that change state) from the read side (queries that return data), so each can optimize independently. When to use CQRS Read/write needs are very different: Reads are hot and need tailored projections, denormalized views, caching, or a different store. Writes need strong validation, invariants, and transactions. Performance and scaling: Reads outnumber writes by a lot (10×–100×), and you want to scale/read-optimize without complicating write logic. UX wants different shapes than your domain: E.g., “Order with line items and fulfillment status by customer” needs a custom read model that doesn’t match your normalized write schema. Complex domains: Clearer boundaries and testing by separating write rules (invariants) from read concerns (reporting, search). Event-driven systems: You already publish events and can build read models/projections asynchronously. When not to use CQRS ...

Event Sourcing in one line Store every state change as an event in an append-only log; rebuild state by replaying events and serve reads from projections. When to use Event Sourcing You need a full audit/history of changes (who did what, when). Complex domain invariants benefit from explicit events and replay. You want temporal queries (state as of time T) or easy rebuilds of new read models. Distributed workflows where event streams are the source of truth. You already embrace CQRS and projections (read models). When not to use it ...

Goal Ship a .NET service to EKS with a clean pipeline: GitHub Actions uses OIDC (no long‑lived AWS keys) Builds and pushes image to ECR Helm deploy with safe rolling updates (optional canary) Connect to RDS with TLS Optional: upload static assets to S3 Repo layout . ├── src/MyApi/. │ ├── Program.cs │ ├── MyApi.csproj │ └── Dockerfile ├── charts/api/ # simple Helm chart for the API │ ├── Chart.yaml │ ├── values.yaml │ └── templates/ │ ├── deployment.yaml │ ├── service.yaml │ ├── hpa.yaml │ └── ingress.yaml └── .github/workflows/deploy.yml Dockerfile (multi-stage, non‑root) ...

Timeless design patterns for reliable, scalable microservices.

Timeless design patterns for reliable, scalable microservices.

C# 12 is out and C# 13 is coming—see what’s new