Microservices promise independence, resilience, and the freedom to scale individual concerns. In practice, decomposing a monolith without a clear strategy routinely produces a distributed monolith — all the operational overhead with none of the agility benefits.

This article walks through the three decisions that matter most: identifying service boundaries using domain-driven design, choosing synchronous vs. asynchronous communication patterns, and establishing a deployment topology that keeps blast radius small.

Key topics covered

• Defining bounded contexts as service boundaries
• Choreography vs. orchestration for inter-service communication
• Circuit breakers, retries, and bulkhead isolation
• Contract testing with Pact to prevent integration drift

The accompanying GitHub repository contains a fully working reference implementation using .NET 8, AWS ECS, and an API Gateway — annotated with the decision rationale at each step.

Point-to-point integrations accrue coupling debt silently — each new consumer requires a producer change, and over time the graph of dependencies becomes brittle. Event-driven architectures invert this relationship: producers emit facts; consumers react independently.

AWS EventBridge makes this pattern operational at scale. This article covers schema registries, cross-account event buses, dead-letter queues, and replay strategies — the production concerns that tutorials typically skip.

Key topics covered

• Modelling domain events vs. integration events
• EventBridge rules, targets, and filtering patterns
• Idempotent consumers and exactly-once semantics
• End-to-end tracing with AWS X-Ray

The sample project demonstrates a real-world order processing pipeline with five decoupled Lambda consumers and a full CloudFormation deployment template.

Domain-Driven Design is frequently treated as a naming convention — entities, aggregates, repositories — applied to an existing data model. That misses the point entirely. DDD is a collaboration discipline first and a code-structuring discipline second.

This article focuses on the front-end of the DDD process: event storming, ubiquitous language, and how bounded contexts translate into team topology and deployment units rather than just package names.

Key topics covered

• Running a productive event-storming workshop
• Aggregate design and consistency boundaries
• Context mapping patterns: ACL, shared kernel, published language
• When DDD is overkill (and what to use instead)

The GitHub repository includes a worked example applying these concepts to an e-commerce domain, with before/after comparisons showing the impact on code structure and team ownership.

OAuth 2.0 solves authorisation delegation. It does not solve rate limiting, input validation, injection prevention, or the dozens of other concerns that sit between "authenticated request" and "safe system". Treating token validation as the whole of API security is a recurring root cause in incident reports.

This article systematically works through the OWASP API Security Top 10, pairing each risk with a concrete mitigation pattern and where it belongs in a layered defence model.

Key topics covered

• mTLS for service-to-service authentication
• Fine-grained authorisation with AWS Verified Permissions
• Threat modelling APIs with STRIDE
• Secrets management and rotation with AWS Secrets Manager

The companion repository provides a hardened AWS API Gateway configuration with WAF rules, Lambda authorisers, and an automated security regression test suite.

Command Query Responsibility Segregation is one of the most cargo-culted patterns in enterprise software. Applied indiscriminately it adds ceremony without benefit; applied to the right problems it unlocks read scalability and audit capability that a single-model architecture simply cannot deliver.

This article draws a clear line between the problems CQRS solves and those it creates, and presents a decision framework for identifying the bounded contexts within a system where the pattern earns its complexity cost.

Key topics covered

• Read vs. write model divergence as the forcing function
• Event sourcing as a persistence strategy for the write side
• Eventual consistency trade-offs and user experience implications
• Projection rebuilding and snapshot strategies

The reference implementation uses .NET 8 with MediatR, an EventStore write side, and a DynamoDB read projection — deployed on AWS with full infrastructure-as-code.

Monitoring tells you something is wrong. Observability tells you why. As systems become more distributed the gap between these two capabilities becomes the gap between a 15-minute and a 3-hour incident. Getting there requires more than adding more dashboards.

This article covers the three pillars of observability — structured logs, metrics, and distributed traces — and how to instrument a .NET microservices system so that the first question in any incident ("where did it fail?") is answerable in under two minutes.

Key topics covered

• OpenTelemetry instrumentation for .NET services
• Correlation IDs and trace context propagation
• Structured logging with Serilog and AWS CloudWatch Insights
• SLO-driven alerting with CloudWatch Composite Alarms

The GitHub project includes a multi-service Docker Compose environment pre-wired with Jaeger for traces, Prometheus for metrics, and Loki for logs — so you can explore the full observability stack locally before deploying to AWS.