{
  "id": 4994979,
  "title": "Building an investing knowledge graph, part 5: what LIVE actually means",
  "url": "https://urgent.news/2026/09/02/building-an-investing-knowledge-graph-part-5-what-live-actually-means",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-02T02:37:13.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/hannune/building-an-investing-knowledge-graph-part-5-what-live-actually-means-18g3"
  },
  "original_language": "en",
  "account": "Part 5 explores the meaning of \"LIVE\" in the context of an investing knowledge graph. When the resolver was first called locally, everything worked fine. However, once an external caller, such as a third-party service, started using the API, new issues arose.\n\nInitially, the error budget was internal and easy to manage since the single caller always handled failures. But when external callers began returning errors, the situation changed. A 500 error response with a generic message appeared for a request that had previously worked in local testing. This was due to the API hitting the registry backend during a mid-write transaction, causing inconsistent data responses.\n\nThe issue stemmed from the locally used file-based registry backend, which had no durability problems. The production backend, however, switched to PostgreSQL via Supabase, using transactions to ensure data consistency. Reads now receive a consistent snapshot of the registry, and writes and reads are atomic.\n\nThe transition to the new backend was straightforward, as the application logic remained unchanged; only the persistence layer changed. Railway's default zero-downtime deployment handled the deployment process by routing traffic only after the new service passed its healthcheck. This ensured that no request reached the new version before it was completely ready.\n\nThe healthcheck endpoint returns a 200 status when both the API and the registry backend are ready to serve requests. This is crucial because startup takes time, and an incorrectly configured healthcheck could route traffic to an instance that's not fully operational, generating confusing errors.\n\nThe registry currently holds nearly 48,000 entities and aliases. Most entries are stable, but some are likely incorrect due to the model's permissive threshold during early calibration. To address this, a review layer is in place for pairs scored as probable matches but below a high-confidence threshold. These pairs go into a pending state, requiring review before being added to the stable registry. Current API responses only include stable entries, filtering out any pending pairs.",
  "summary": "Building an investing knowledge graph, part 5: what LIVE actually means Part 4 ended with the resolver working locally and me calling it live on Railway. That framing glossed over a gap. Something running locally and something running in production are different in ways that are obvious in retrospect and invisible until they bite you. Here's what changed once I had a caller that wasn't me. The…",
  "key_points": [
    "LIVE in knowledge graph context causes issues when external callers return errors",
    "API hits PostgreSQL registry backend during mid-write transaction, leading to inconsistent data",
    "Healthcheck endpoint ensures new service is fully operational before routing traffic"
  ],
  "editors_take": "The shift to a PostgreSQL backend ensures that the investing knowledge graph provides consistent data responses, even with external callers, by guaranteeing atomic writes and reads.",
  "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."
}