I've designed such a "classic mistake".

> In addition, it doesn't give you various features such as tagetting by users, segments, etc. Nor does it give you things like progressive rollout or automated rollback (yes we were using that in house and had saved us at least a few times).

These are things you can think of quite easily, or you just survey the landscape of what challenges other implementations run into and they inform you of this. The first iteration of our design had all of those; we could target users, always-subscribe internal users, we could have two features have the same segment/ordering of rollout, etc.

Database load wasn't ever a problem, because you're talking about quite literally a single SELECT on an already established & otherwise in use DB connection. But caching is not that much to bolt on afterwards should it become an issue.

It's never been clear to me that the simplicity of understanding that a single query has, even if it might be short a few features, is outweighed by the complexity of a full dependency to an external service.

As it was, our FF system outlived the company, and was sunset when the company ended.

Eh, I built a feature flagging system for service with millions of daily active users and it: wasn't hard to do, was easy to extend to support targeting, segments, and progressive rollout, and on top of it flags are easy to cache, so the database pressure was not that big. We did this long before LLMs, and it occupied maybe a month of engineering time for me, here and there as we needed new features, while I was doing other things. We did choose the wrong hash for bucketing in the beginning, but we noticed the stairstep patterns in our buckets quickly (an advantage of having millions of requests per day to measure) and picked a better one. It was much better this way since it meant backend flags without a roundtrip to a 3rd party service (that was the main motivation, we wanted this kind of control without adding latency to our requests). I remain baffled by launch darkly or other such services. And today, with LLMs, just build it yourself is hard to argue against.

My website company 20 years ago was running Memcached keys for each of the feature flags so they only had to be loaded about once per session from the DB most of the time.

Scaling things like this is a mostly solved problem. Having your website load when the DB is down is not.

Wouldn't you be having bigger problems if the DB is down (especially if you have good defaults for the flags)?

Have a safe default fallback.