Design Patterns
Why the architecture looks the way it does — illustrated, persona-driven pattern studies with a diagram for every question.
Designing DNS for a Kubernetes Estate: One Architecture at Five Resolutions
Cluster DNS is invisible until it is expensive, and the limit that ends most DNS incidents is not a queries-per-second number at all. This interactive redraws one name-resolution architecture five times at increasing resolution. Three passes share a fixed topology — a shared-services account owning the resolution edge (the VPC resolver, an outbound endpoint carrying queries to on-premises, an inbound endpoint carrying them back, the private hosted zones and the forwarding rules) beside a workload account running EKS with CoreDNS, the add-on autoscaler and a node-local cache in front of the pods. Two passes deliberately break that constancy, because a requirements bar and a capability model have no deployment shape. Three purpose-built canvases open up what the topology cannot show: inside one CoreDNS pod, where the default Corefile is read as an ordered chain and a query leaves at the first plugin that can answer it; the estate, where one resolution edge is built once and associated to every VPC while CoreDNS stays per cluster because it answers from that cluster's own API server; and the four published ceilings, including the 1024 packet-per-second link-local allowance that is shared with the instance metadata and time services and rejects rather than queues. Each of the 22 steps carries the decision behind it — options considered, the recommendation, the reason, the cost accepted — with five one-way doors flagged — including how a name is published outward, and whether one name works from both inside and outside the cluster. Behaviour, defaults and limits checked against the Kubernetes, CoreDNS and AWS documentation in August 2026.
Designing Argo CD for a Multi-Account Estate: One Architecture at Five Resolutions
GitOps at fleet scale is not a diagram — it is a stack of decisions, and the expensive ones are made before anyone installs the Helm chart. This interactive redraws one Argo CD architecture five times at increasing resolution. Three passes share a fixed topology canvas that spans two clouds inside a dashed delivery boundary — Environment (the estate, the reach the control plane actually needs, what is inherited rather than owned), Logical (argocd-server, the ApplicationSet controller, the application controller, the repo server, Redis, and the flows between them), and Physical (what is deployed, how the reconciler tier is sized, how it authenticates across accounts, and how you stay on a supported version) — so you can follow one concern, how a change reaches a cluster, from "the control plane must reach every cluster API" down to "only :443 outbound, and the controller is the only component that writes." Two passes deliberately break that constancy, because a requirements bar and a capability model have no deployment shape. Three purpose-built canvases open up what the topology cannot show: inside one control plane (the two independent work queues, --status-processors and --operation-processors, the plugin sidecar, and Redis' nine caches with their expiry windows), the estate (one shared tier that is not divided at all, three controller replicas that are, and clusters assigned to them whole — which is why one very large cluster pins a shard and sets the ceiling), and how drift is noticed (three triggers converging on one comparison, then the branch on syncPolicy). Every step carries the decision that put the element there: the options genuinely considered, the recommendation, the reason, and the cost you accept. Behaviour, defaults and flag names checked against the Argo CD documentation in August 2026 (v3.5.x).
Designing Istio for the Enterprise: One Architecture at Five Resolutions
A multi-cloud service mesh isn't a diagram — it's a stack of decisions, and the expensive ones are made long before anyone writes YAML. This interactive redraws one architecture five times at increasing resolution. The mesh boundary itself is drawn — a dashed envelope showing that one trust domain spans both estates, with trust, config and consumers all arriving from outside it. Three passes share a fixed nine-block topology canvas — Environment (the estate, the real network, the compliance bar), Logical (istiod, Envoy sidecars, east-west gateways, the CA chain, GitOps delivery, the flows between them), and Physical (replica counts, sizing, internal NLBs, subnets, ports, Direct Connect, cert TTLs) — so you can follow one concern, cross-cluster connectivity, from "pod CIDRs aren't routable between clouds" down to "east-west gateway ×3 behind an internal NLB on 10.20.0.0/24, only :15443 open." Two passes deliberately break that constancy, because a bar and a capability model have no deployment shape: Requirements is a board — four functional requirements, seven non-functional dimensions each stated with how it is verified, and constraints listed with the team that owns them — and Conceptual is a capability model layered by dependency, with a capability→component table bridging it back, because a capability model that inherits the topology is just a logical design with the product names filed off. Each of the 47 steps carries the decision that put the element there: options genuinely considered, the recommendation, the reason, and the cost you accept — with the five one-way doors flagged. Drawn from a 75-decision, 13-domain register, plus rollout phases, ownership split, and the risks most likely to bite.
The One-Page ADR: Context, Decision, Consequences
If a decision isn't written down with its context and consequences, it will be relitigated — or worse, silently eroded by someone who never knew it was load-bearing. The Architecture Decision Record is the cheapest tool in architecture, and one page is a forcing function, not a constraint. What earns an ADR (the one-way-door test: expensive to reverse, crosses team boundaries, constrains the future), the anatomy section by section (Status as a lifecycle, Context written for a reader two years out, Decision in one active sentence, Consequences with costs not just benefits, Options considered as the section that stops relitigation), a real one-pager written in full (a dedicated network pipeline split from AFT), why one page, the operational side most advice skips (in-repo, PR-reviewed, superseded not edited), and ADRs as an influence instrument — how a decision log scales your judgment to teams you'll never meet. Template + a two-question test included.
The Paved Road Problem: Driving Adoption Across Teams You Don't Control
You built something better — a platform, a workflow, a golden path — but you can't make anyone use it, and "it's better, trust me" has never once been enough. Why the mandate reflex backfires (resentment, shadow workflows, adoption theater), the pattern that works instead — the paved road / golden path (Netflix, Spotify, Google) run as a product whose only success metric is voluntary adoption — and 12 concrete plays that win adoption by pull: make it the path of least resistance, self-service scaffolding, lighthouse teams, migrate-by-default, strangle the old road, and mandate only the safety floor. Measure usage, not installs. Every claim sourced.
Shift-Left, Explained: Catching Failures Where They're Cheapest
Move testing, security, and validation from post-merge toward pre-commit, so the machine tells the author it's broken while the fix still costs minutes. What shift-left actually means beyond the buzzword; why the famous "10x cost of a defect" number is folklore (and what's true instead); designing a tiered pipeline — a fast required pre-merge tier vs a deep nightly one; twelve concrete practices enterprises actually run (pre-commit hooks, merge queues, SAST, secret + dependency scanning, policy-as-code, contract tests, preview envs, test-impact analysis, feature flags) with real tools and where each shifts; the metrics that prove it (escape rate, time-to-first-signal, DORA); and the culture shift that makes or breaks it. Every claim sourced.
Multi-Agent Orchestration
The seventh article in the agentic series: when one agent's context gets too crowded with tools and instructions, you split it into many — but the agents were never the hard part, the handoffs are. Why you split at all (context isolation, specialized tool sets, parallelism) and why you shouldn't until one agent genuinely breaks; the three topologies on one spectrum (supervisor/worker as the default, hierarchical supervisors-of-supervisors for scale, swarm peers with no boss); why the handoff — what state transfers, what's summarized, what's dropped — is the real system; containing the blast radius when one sub-agent fails or loops; A2A handoffs across team/org boundaries; and how to choose a topology. With flow diagrams and runnable LangGraph code.
Human-in-the-Loop Approval for Autonomous Agents
The sixth article in the agentic series: autonomy removed the human checkpoint that used to sit between intent and consequence, and HITL puts a calibrated one back — without it, an agent's first catastrophic mistake is also its last. Why approval is an architecture decision, not a UX afterthought; gating by risk class rather than by step (reversible/cheap actions run free, irreversible/expensive ones pause); the mechanism — pause and resume on the checkpointer, so a paused graph survives a restart; the failure mode on the safe-looking side (approval fatigue, where too many prompts train humans to rubber-stamp); HITL vs HOTL (does the gate block, or just observe?); designing the wait itself (timeouts, escalation, what the human sees); and a pre-ship checklist. With flow diagrams and runnable LangGraph interrupt() code.
Agent Security & Prompt Injection
The fifth article in the agentic series, and a design pattern rather than a primer: prompt injection isn't a bug you patch, it's an architecture an attacker hijacks with a sentence hidden in a web page. Why it's an architecture problem, not a prompt problem; the threat model (the lethal trifecta — untrusted content + private data + the ability to act, and why any one missing leg defuses it); the root cause (the confused deputy — the model can't tell your instructions from the attacker's); the defense patterns in priority order (least-privilege tools, separate read from act, sandbox the execution, human-in-the-loop for high-risk actions), each traced as vulnerable-vs-hardened wiring in code; layering them as defense-in-depth; and a pre-ship security checklist. With flow diagrams and runnable LangGraph code.
Event-Driven Architecture
The EDA design pattern on AWS: events vs commands and the temporal/location decoupling pub-sub buys (and the schema coupling it doesn't), choreography (services react to events with no coordinator — EventBridge/SNS/SQS, independent scaling, but no central view of the flow) vs orchestration (a coordinator directs the workflow — Step Functions, with branches, the waitForTaskToken callback, and one inspectable execution), the decision and why most systems hybridize (orchestrate within a domain, choreograph between), the saga pattern, the toolbox (EventBridge buses/rules/Pipes, SNS vs SQS, Standard vs Express), and the operational realities — at-least-once delivery and idempotency, ordering, DLQs, and tracing. 27 questions with a diagram for each.
Multi-Region Disaster Recovery
The DR design pattern on AWS: RTO vs RPO, and the four strategies on a cost-vs-recovery continuum — Backup & Restore (hours), Pilot Light (core on, app off), Warm Standby (scaled-down but serving), and Multi-site Active/Active (near-zero, no failover). Cross-region data replication (Aurora global database, DynamoDB global tables and last-writer-wins), Route 53 / Global Accelerator failover, the data-plane-not-control-plane discipline, why replication isn't a backup, and how to choose by RTO/RPO. 27 questions with a diagram for each.
Centralized Egress Inspection (AWS Network Firewall)
The design pattern for inspecting all internet-bound traffic at one exit: spoke VPCs route 0.0.0.0/0 to a Transit Gateway into a dedicated inspection/egress VPC, where AWS Network Firewall filters traffic (before NAT, so it sees the real source) ahead of a NAT gateway and IGW. The subnet tiers, the exact route tables, the appliance-mode nuance (egress vs east-west), the firewall-subnet isolation rule, HOME_NET, cost (NAT consolidation + the firewall/NAT waiver), and when to choose this vs GWLB or distributed. 27 questions with a diagram for each.
Central Ingress Pattern (AWS, multi-account, multi-region)
Why centralize inbound traffic: the pattern and account model, the three ingress cores (Transit Gateway vs Cloud WAN vs Gateway Load Balancer), traffic flow and the asymmetric-routing trap, inspection & security, multi-region failover, cost/FinOps, and operations — answered through the five personas who actually build and run it.
No posts match — try a different keyword or clear the filters.