Most engineering teams rewrite their systems three times. The first is largely unavoidable. The second is potentially avoidable. The third is self-inflicted, and it is the one that kills velocity. The pattern is consistent enough that you can use it as a...

Most teams treat testing as something you do after building. You write the code, wire up the infrastructure, and then figure out how to test it. The result is a test suite that requires a running database, a message broker, a cache, and maybe a stable...

Most audit logs are full of lies. Not malicious ones. They are lies of omission: the row that got updated in place and took the history with it; the audit write that was added to three of five code paths and nobody noticed the gap; the log that records the...

A payment processed twice is not a bug report. It is a regulatory incident, a customer complaint, and depending on the jurisdiction, a compliance violation. Most teams treat idempotency as a hardening pass they will get to later. In practice, "later" means...

"Keep it simple" has always sounded like good advice and felt like a platitude. Easy to say in a conference talk. Hard to defend when the CTO at the last company used Kafka, when the job postings all list Kafka, Kubernetes, Terraform, 3 obscure databases and...

The default "event-driven architecture" looks like this: lots of small services connected by queues, with event objects flowing between them. Events, signals, and queues get lumped together as one concept. "An event is a data structure that sits on a queue...

At the end of a long day immersed in the world of software and systems, (occasionally in the middle if working from home), I sometimes relax by cooking myself a meal. I am but a lowly home cook, but I feel that I've learned something over the years. When...

The most common first question in a new system design is "what database should I use"? The second is usually "should this be a microservice"? Both are premature. Before you pick the infrastructure, model the domain. Your system is a state machine whether you...

"Don't use your database as a queue" is one of those pieces of engineering orthodoxy that gets repeated so often it starts to feel like a law. It isn't. It's a guideline with a scale constraint attached, and for most workloads that constraint is never...

Most architecture discussions for new products begin with "should this be a microservice"? It is almost always the wrong first question. The right first question is: what needs to own state, and what just needs to do work? This article describes a topology...

Agile has a reputation problem. Depending on who you ask, it's either the salvation of software delivery or the source of its dysfunction. Multiple meetings that waste everyone's time. Sprints that deliver activity but not progress. Velocity charts that...

The modern scaling landscape is overwhelming. Queues, event buses, microservices, serverless, Kubernetes. The list of "essential" technologies grows longer every year. It's very easy to get lost in the choices, and even easier to feel pressure to adopt...

Ask an AI to review your architecture proposal. It will find things to praise. Ask if your approach is sound. It will tell you "of course it is". Ask what could go wrong. It will list some things, helpfully, then conclude that your approach is solid overall....

SQLite gets dismissed as a toy database. It ships with Python, it is the default for mobile apps, and it turns up in tutorials about learning SQL. None of that is wrong, but it obscures what SQLite actually is: a highly capable, in-process relational engine...

As a technical system grows in scale and complexity, teams require more checks, balances, and standards to keep development manageable and maintain delivery velocity. While practices like feature flags and contract testing are common at this stage, one...