Articles
Worth reading
A short take on pieces worth your time — architecture, AI, system design, and engineering careers — each one linked back to its original source.
6 articles
Scaling beyond one: How Airbnb evolved its data architecture for a multi-product world
Airbnb's data engineers walking through what happens to a decade-old data model when the product stops being "one thing" — Homes — and becomes three (Homes, Experiences, Services) at once: the consistent, flexible modeling framework they built so the same metrics and pipelines don't fork three ways. It's a useful case study in designing for extensibility in a data platform, not just a services layer, which is the part of "architecture" that gets talked about far less than it should. Relevant well beyond travel and marketplace companies — anyone with a growing product surface will recognize the problem.
The Death of Microservices Hype: When Modular Monoliths Win
A sober look at the 2026 correction away from "microservices by default": teams that adopted them before they had the scale to justify the operational cost are quietly moving back toward modular monoliths — a single deployable unit with real internal module boundaries, rather than either a tangled legacy monolith or a fleet of distributed services. The honest takeaway isn't "microservices were wrong," it's that the decision needs to follow actual scale and team-topology pressure, not architecture-conference hype.
Strangler Fig
The pattern for replacing a legacy system without ever staging the terrifying "big bang" cutover: put a facade in front of the old system, and move functionality behind it into the new system piece by piece until there's nothing left to strangle. I've seen a version of this used on more than one banking migration, and the value isn't the metaphor — it's the discipline it forces, routing real traffic through the seam from day one instead of building the replacement in isolation and hoping the switchover goes smoothly. Short, practical, and still the reference point everyone eventually points to.
Introducing Domain-Oriented Microservice Architecture
Uber's insight here is one I wish more teams internalized before splitting a monolith: a microservice architecture is still just one large distributed program, and it benefits from the same domain boundaries and layering discipline you'd apply to any big codebase — they just happen to be enforced by network calls instead of package boundaries. DOMA's structure (domains, gateways, layers) is a genuinely useful vocabulary for reasoning about service sprawl instead of just letting it happen organically. Good read once your service count has outgrown your ability to reason about it.
Designing robust and predictable APIs with idempotency
The article that made idempotency keys a standard expectation for any payments-adjacent API: pass a client-generated key with a request, and retries — from a flaky network, a timeout, a naive retry loop — become safe instead of a double-charge waiting to happen. It's a deceptively simple pattern that solves a real and expensive class of production bugs, and this writeup is still one of the clearest explanations of why "just retry on failure" is dangerous without it. Essential if you're designing any API that touches money or triggers a side effect that can't be undone.