CepatEdge

Appearance

Maintenance cache lifecycle ​

Role ​

Maintenance cache accelerates list and detail reads for maintenance_requests, aligned with MaintenanceCacheService (or successor) in apps/worker.

This document states behavioral contracts; wiring details live in code and ../../architecture/cache-multi-shard-summary.md where relevant.

Write path (mutations) ​

  1. Always persist to the database first (source of truth).
  2. On success:
    • Invalidate or replace cache entries for:
      • The specific request (by id).
      • Any list or aggregated cache keys that include this request (department lists, user dashboards, etc.).
  3. Terminal transitions that write finalSnapshot must commit atomically with the row update (see ../maintenance/snapshot-behavior.md).

Read path ​

  1. On read, prefer cache if valid for the requested scope (detail by id, filtered list).
  2. On cache miss, load from DB, optionally hydrate relatedUsers for open tasks via user.md, then store in cache per TTL/policy.

Closed tasks ​

Purge ​

Hard delete removes the row and must:

  • Remove or invalidate all cache keys pointing at that id (detail, lists, aggregates).