Common architectural and software design patterns
Eventual consistency in DDD works when the inconsistency window is a business number. Build a .NET saga with outbox and idempotent consumers, then alert on it.
A high coverage number can hide tests that never verify real behavior, tests that run every line without checking whether the logic is actually correct. Mutation testing exposes those gaps by deliberately breaking your code and checking whether any test notices, turning test quality into a number you can measure instead of assume.
Event Sourcing stores every state change as an immutable event, so your database keeps the full history. When to use it, and a working C# implementation.
I watched one misconfigured service take down an entire platform because everything shared the same resource pools. Here is the bulkhead pattern that prevents it, with a working .NET 8 demo you can run locally in minutes.
Most teams consult specifications when things break. Spec-driven development turns that around, making the spec the source of truth before a single line of code is written. This post covers the four pillars of SDD, a step-by-step Claude Code walkthrough using FHIR validation, the current tooling landscape, and an honest look at where the practice still falls short.
A few years ago, I worked on a customer loyalty platform for a large retailer. Every time a customer made a purchase, multiple systems needed to react. The billing system had to record the transaction. The loyalty engine had to calculate points. The marketing platform needed purchase data to trigger campaigns. At first, the team considered wiring these systems directly together. The billing service would call the loyalty service. The loyalty service would notify marketing. And so on. But within a few weeks, the design looked like spaghetti. Every new requirement added another direct dependency. One change in one system caused a ripple effect across the others. We needed a way for systems to talk without being tightly tied together. That’s when the Publisher-Subscriber pattern became the answer.
It was just past midnight when my phone buzzed. Again. "Payment service failure. Error rate: 96%. Retry storm detected.". I was leading the architecture team of a retail tech platform with millions of daily users. We were in the middle of our summer sales campaign, traffic was peaking, and all eyes were on system stability. A minor hiccup with a third-party payment gateway had escalated into a full-blown meltdown. Shopping carts froze. Transactions stalled. The user experience team was already fielding complaints on Twitter. The root cause? Not the gateway itself, but our system’s reaction to it. We had built something fast and feature-rich, but not fault-tolerant. That night, I learned a hard but transformative lesson about the Circuit Breaker pattern.
The BFF pattern gives each frontend its own backend, so mobile, web and TV stop fighting over one shared API. When to use it, and when it is just overhead.
It started with a phone call late on a Thursday. "We’re bleeding money on support. Customers are churning. And that monolith is held together with duct tape and prayer. Can you help?". As a solution architect, this is the moment the real work begins. The system in question was a 15-year-old CRM built in a now-defunct framework, with business logic buried so deep even the original developers would need breadcrumbs to find their way back. But a full rewrite was off the table. Too risky, too slow. They needed a change that was incremental, controlled, and safe. That’s when we reached for a proven technique: the Strangler Fig Pattern.
A solution architect at a mid-sized fintech startup was wrapping up a Friday afternoon design review when an alert came in. The customer onboarding API was intermittently failing. Not enough to trigger a full incident, but enough to raise eyebrows in the compliance team. At the root of the problem? A background verification callout to a third-party KYC (Know Your Customer) service. When that service hiccupped, the onboarding flow stalled. And because it was a synchronous call in a tightly coupled microservice, retries weren’t consistent. Worse, the core service logs showed nothing. The failures were silent.