AI and Systems Architecture

In 2026, enterprise AI isn't failing because models are bad. It is failing because organizations are building brittle demos instead of bounded, operable systems.

Privacy is an architecture constraint, not a feature toggle. Teams that build sovereignty into their systems early avoid painful retrofits and close enterprise deals faster.

Production AI architecture patterns for gateways, retrieval, evaluation, fallbacks, cost control, and ownership.

Multi-agent systems aren't magic. They're distributed systems with all the usual coordination headaches. Here are the four patterns I've seen work, and when each one falls apart.

Model Context Protocol promises to standardize how AI talks to tools. I built an MCP server in Go to see if the promise holds up. Here's what I found.

AI infrastructure at scale is just infrastructure. The same boring patterns -- gateways, caching, circuit breakers, budget enforcement -- solve the same boring problems.

Single-prompt agents break on real tasks. Plan-execute-replan, orchestrated specialists, structured memory, and explicit recovery -- in Go -- are what actually works.

Everyone reaches for GPT-4 by default. Most production tasks don't need it. Small models are faster, cheaper, and often better when the task is well-defined.

Bigger context windows aren't an excuse to stop thinking about what goes into them. Most teams are paying for irrelevant tokens and wondering why quality degrades.

Betting on a single model provider is like having a single database with no failover. Here is why multi-model is the only sane production strategy.

The architecture of an AI-native app is fundamentally different from bolting a model onto a CRUD app. Here is how I structure them -- with code, layers, and hard-won opinions.

OpenAI DevDay was not just a product launch. It was a platform play that changes the build-vs-buy calculus for every team shipping AI features.

Most agent demos are impressive. Most agent production systems are not. Here is what separates the two.

RAG is the default architecture for grounding LLMs in private data. Here are the patterns that survive real traffic, with Go examples from production systems.

GPT-4 landed and everything changed. What I learned in the first week of building with it, and the architecture decisions that followed.

Practical patterns for integrating LLMs into real applications -- prompt management, structured outputs, caching, fallbacks, and tool use -- with Go examples.

Monorepo or polyrepo depends on coupling, team shape, and your appetite for build tooling. Here is how to decide without getting religious about it.

Async patterns solve real problems -- bursty traffic, slow dependencies, decoupled teams. But the complexity tax is real. Lessons from building event-driven systems at Decloud.

Rate limiting algorithms, implementation tradeoffs, and practical lessons from building limiters for high-traffic APIs at a real-time messaging company.

The patterns that actually survive production across failure handling, consistency, messaging, coordination, and scaling.

Service meshes solve real problems at real scale. But most teams adopt them before the problems exist. Here's how to decide honestly.

API versioning is a maintenance commitment, not a design exercise. URL paths win for public APIs, headers for internal ones. The real discipline is not versioning -- it's avoiding breaking changes in the first place.

December 7 reminded everyone that us-east-1 is a single point of failure for half the internet. Again. I am annoyed.

Event sourcing is powerful but expensive to get wrong. Here's what actually works, with Go code, drawn from building event pipelines at the fintech startup.

The term 'technical debt' has become meaningless. Everything inconvenient is debt. Here's what it actually is, when it matters, and why most teams handle it wrong.

Zero trust from two perspectives: my NATO background in defense systems and work at a major telecom. The architecture patterns, the implementation path, and what most companies get wrong.

Serverless databases are solving problems most teams don't have. Here's why Postgres with a connection pooler is still the right answer.

Edge gateways, BFFs, and service mesh ingress -- what I've learned running them at Decloud and at large telecoms.

Multi-cloud sounds great in vendor pitches. In practice, it doubles your operational burden for benefits most teams will never need.

I've built a custom Go gateway, run Kong in prod, evaluated Envoy, and used managed cloud gateways. Here's what I actually recommend after doing all of them wrong at least once.

Most teams adopting GraphQL federation don't need it. A frank take on when it makes sense, when REST is fine, and why conference talks are a terrible basis for architecture decisions.

Lessons from building event-driven systems at the fintech startup and Decloud. What actually works, what silently corrupts your data, and Go patterns for handling events without losing your mind.

Serverless is great until it isn't. A comparison of serverless and containers at different traffic scales, with actual numbers on where the economics flip.

After dealing with versioning messes at multiple companies, I landed on URL path versioning for anything public. Here's why the alternatives didn't survive contact with reality.

A practical breakdown of replication modes, topologies, and the tradeoffs between consistency, availability, and not losing your users' data at 3am.

Cloud cost management isn't a finance problem. It's an architecture problem disguised as a spreadsheet. Here's how to treat your AWS bill like the engineering signal it actually is.

Edge computing is real, but most teams adopting it don't have an edge problem. They have an architecture problem they're solving with geography.

Queues look simple on a whiteboard. Then you deploy them. Here are the messaging patterns I've learned the hard way across three startups, with Go code and real failure stories.

Most data problems are ownership problems. Data mesh gets that right. But adopting it as an architecture diagram exercise misses the point entirely.

Most teams shouldn't be migrating to microservices. Here's how to tell if you actually should, and how to do it without wrecking your delivery for eighteen months.

Multi-region architecture is a strategic decision most teams make too early. Here's when it actually pays off, the patterns that work, and why data is the part that will ruin your week.

Failure is not an edge case. It is the default state you temporarily hold off with good engineering. A few hard-won rules for building systems that bend instead of shatter.

Hard-won patterns for reliable background job processing -- queues, retries, idempotency, and the failures that taught me to care about all three.

Algorithms, headers, and deployment patterns for rate limiting APIs -- drawn from building financial data services at the fintech startup.

Hard-won lessons from designing distributed systems that survive real-world failures -- timeouts, retries, bulkheads, and the operational habits that actually keep things running.

Real patterns and antipatterns from running serverless at the fintech startup. Where Lambda shines, where it hurts, and how to tell the difference before it's too late.

Most teams shard too early. Here's how we thought about it at the fintech startup, when it actually makes sense, and the SQL-level decisions that matter most.

You split the monolith. Now every service-to-service call is an attack surface. Here's how I think about identity, authorization, encryption, and secrets management in distributed systems.

Lessons from building event-sourced systems at the fintech startup -- the patterns that held up, the modeling mistakes that bit us, and the operational realities nobody warns you about.

Perimeter security is dead. At the fintech startup, I ripped out the castle-and-moat model and replaced it with zero trust — identity-first, micro-segmented, no implicit trust anywhere. Here's what that actually looked like.

A two-number scoring system for tech debt that tells you what to fix now, what to schedule, and what to quietly accept.

We serve financial data to users across Europe at the fintech startup. Here's what I've learned about going multi-region -- the patterns that work, the ones that burn you, and when you should even bother.

Most serverless tutorials teach you the wrong thing. Here's what matters when you're running it for real.

We tried multiple API versioning approaches at the fintech startup. URL path versioning won. Here's why, plus how to handle deprecation without burning your consumers.

Every pipeline I've built at the fintech startup broke at some point. Here's the design approach that made them recoverable instead of catastrophic.

Lessons from building event-driven systems at the fintech startup and Dropbyke -- what worked, what broke, and why I'd do it again.

Everyone wants to debate GraphQL vs REST like it's a religion. It's not. One reduces round trips, the other is dead simple to cache. Here's how I actually decide.

How Go became the default backend language at Dropbyke and a fintech startup, what it replaced, and the honest tradeoffs we accepted along the way.

A production-grounded case for exhausting single-server headroom with pooling, replicas, and partitioning before taking on sharding complexity.

Production incidents show where architecture bends and where it breaks. These lessons focus on designing for failure, limiting blast radius, and making recovery routine.

Lessons from building the fintech startup's financial data API: the REST conventions that actually matter, the ones that don't, and why consistency beats cleverness every time.

A grounded look at PostgreSQL and MySQL as of April 2016, focusing on integrity, query power, and operational tradeoffs rather than benchmark hype.

Lambda is a sharp tool for specific jobs. The problem is everyone wants to use it for everything.

A pragmatic look at technical debt in 2016: what it is, how it shows up, how to measure it, and how to make a business case for paying it down without stalling delivery.

Most teams adopt microservices too early and pay for complexity they don't need yet. A well-structured monolith is faster, simpler, and keeps your options open.