{
  "id": 1070641,
  "title": "Your `if` statements are a database nobody can query",
  "url": "https://urgent.news/2026/08/15/your-if-statements-are-a-database-nobody-can-query",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-15T15:54:05.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/fs-doc/your-if-statements-are-a-database-nobody-can-query-3d84"
  },
  "original_language": "en",
  "account": "In the codebase, there exists a line that appears as follows: if (user.plan === enterprise || user.tenantId === acme-corp) { // ... }. It is unclear who authored the second half of this condition, and it has remained unchanged for two years. This line is not actually code, but rather data stored in an unfavorable location. Every conditional that defines a business decision essentially represents a row, containing a condition, an outcome, and implicit context surrounding its applicability. Numerous such rows exist, scattered across various services, expressed in multiple styles, without any means to list or query them. A database would provide numerous benefits over this setup. Firstly, it would establish a schema, ensuring consistency in rule definitions. Secondly, it would enable querying the rules, allowing for easy determination of live rules in production. Currently, someone must manually read the source code to answer this question, which is both time-consuming and prone to error. Secondly, there are no migrations for changing rules. Modifying a rate limit from 100 to 200 necessitates a pull request, review, CI run, and deployment window, essentially transforming a simple change into a full pipeline process. Thirdly, there is no audit log. While Git can track who modified a line, it does not provide information about who decided the rule, when it was supposed to expire, or if the customer it was written for is still active. This lack of accountability hinders proper governance. Lastly, there is no access control. The individual responsible for a pricing policy cannot read the policy itself, forcing them to rely on engineers to locate the information. Consequently, any changes must go through a lengthy sprint process, not due to intentional design but rather the rule's inherent location. These issues are not insurmountable, but rather inherent in the current approach. The typical solution involves moving the rules into a separate service, such as remote configuration, a feature flag platform, or a policy server. This approach indeed offers UI, audit trails, and change management without requiring a deploy. However, it introduces new problems. By offloading rule evaluation to a separate service, the application's request path now includes an additional network call, adding latency, failure modes, and dependency on external uptime. Furthermore, the kill switch, which is crucial for emergency shutdowns, becomes unreliable in this architecture. Flipping the kill switch requires the third-party service to be operational, exacerbating the availability problem during critical incidents. Instead of prioritizing this solution, consider an alternative approach that addresses these problems directly. Begin by defining a declarative format for rules, complete with a schema to validate their correctness. Consolidate all rules into a single artifact, enabling users to view the current live rules instead of engaging in an endless search through code. Ensure that rule changes can be implemented without requiring a deploy, as this aligns with the core objective. Validate the rules to verify their authenticity, ideally by digitally signing them. Finally, evaluate the rules locally within the application, eliminating any intermediaries between the request and its answer. By addressing these requirements, you can create a more efficient and reliable rule management system. GovernPlane is an example of such a system, which compiles rules into a signed JSON bundle. The bundle is shipped through standard configuration mechanisms, such as Git commits or objects in a bucket, and loaded by the application. The bundle undergoes signature verification before evaluation, ensuring the authenticity of the rules. This approach can be applied to various use cases, such as feature flags, kill switches, role-based access control (RBAC), and custom effects. By treating rules as declarative artifacts, rather than embedded code, you can achieve better visibility, changeability, auditability, and control over your system's behavior.",
  "summary": "Somewhere in your codebase there is a line that looks like this: if ( user . plan === ' enterprise ' || user . tenantId === ' acme-corp ' ) { // ... } Nobody remembers who wrote the second half of that condition. It has been there for two years. It is almost certainly still load-bearing. Here is the thing I want to convince you of: that line isn't code. It's data, and it's stored in the worst…",
  "key_points": [
    "Rules scattered across codebase, not queryable",
    "Lack of schema, querying, migrations, audit log",
    "Moving rules to separate service introduces latency and kill switch issues"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}