DEV Community: lackorol

You probably don't need sharding yet

lackorol — Fri, 23 Oct 2026 12:30:00 +0000

You probably don't need sharding yet.

Every time I see a team reach for it, the real problem is further down the stack. Read replicas for read-heavy load. A missing index on the query that's actually slow. Connection pooling so you stop melting the database with 2,000 idle connections. Partitioning to keep hot tables manageable. And honestly, a bigger box, which goes further than most people believe.

Sharding earns its place only when single-primary write throughput is the hard ceiling and nothing else moves it. That is a real wall, but it is much farther out than the roadmap slide suggests.

The trap is growth projections. They are routinely off by 5 to 10x in both directions. If you shard for traffic you don't have, you pay the operational tax now and might never collect the benefit.

So before the rewrite: what specific number are you hitting, and have you proven it's writes and not everything else?

systemdesign #databases #scalability

Here is the question I try to ask before I commit to a design: if I'm still on call for this in

lackorol — Thu, 22 Oct 2026 12:30:00 +0000

Here is the question I try to ask before I commit to a design: if I'm still on call for this in three years, and I have to explain it to a new hire on their first week, is this still the right choice?

It's a surprisingly strict filter. Clever tricks tend to fail it. The thing that looked elegant on a whiteboard becomes the thing you dread paging through at 2am, and the thing a newcomer can't follow without a ten-minute story about why it's "temporary."

Designs that pass tend to be boring in the best way. Fewer moving parts. Names that say what they mean. Behavior you can predict without reading every line. The kind of system where the explanation to the new hire is short, because there isn't much to explain.

Most architecture debates are really about the next sprint. This question stretches the timeline until the short-term cleverness stops looking clever and the long-term cost becomes obvious.

Would the design you shipped this week survive that conversation?

softwareengineering #systemdesign #oncall

Adding infrastructure feels like progress

lackorol — Wed, 21 Oct 2026 12:30:00 +0000

Adding infrastructure feels like progress. You open a PR, something new exists, the diagram gets another box. Removing infrastructure feels like admitting a mistake. The box disappears, and someone might ask why it was there in the first place.

That asymmetry quietly shapes a lot of engineering decisions. Caches get added and almost never questioned again. Queues, feature flags, extra services, a replica here, a sidecar there. Every one made sense the day it shipped. Together they become the thing nobody wants to touch.

The most useful question I hear from strong engineers is the opposite of adding. It sounds like: "What if we just didn't cache this?" Or: "What breaks if we delete this service entirely?" Most of the time the honest answer is "less than you'd think."

Deletion is undervalued work. It rarely gets a demo. It doesn't show up as a shiny new capability. But removing a thing you no longer need lowers the number of ways the system can fail, and that compounds for years.

What's the last piece of infrastructure your team removed on purpose?

softwareengineering #systemdesign #platformengineering