Junior · Explain · Invalidate cached reads after a successful commit

Why does this fixture invalidate after commit, and what inconsistency window still remains when cache removal itself fails?

Think through your answer before opening the explanation.

Production engineering

Reveal answer and reasoning

Database state and a cached representation have separate owners and failure boundaries. This fixture commits a real SQLite source change before removing the corresponding HybridCache key. A controlled rollback leaves both the durable source and the previously valid cached view unchanged. That ordering is useful but does not create one atomic database-and-cache transaction. The portable program demonstrates a smaller source/snapshot relationship with ordinary variables.

The real package, actual persisted update and source-read counters establish the external behavior. No secondary distributed cache or cross-process invalidation system is configured behind the example.

If removal fails after commit, the source may already be newer than the cached value. Returning an error cannot automatically undo the committed database change. Invalidating before commit can also introduce its own race with readers repopulating an old value. Versioned keys, bounded staleness, expiry and reconciliation address different requirements; none should be presented as a free universal fix. The current one-instance ordering is deliberately narrow.

A production design must state how long stale data is tolerable and which owner can discover or repair it, rather than calling any commit-followed-by-remove sequence perfectly consistent. The source-read counter is separate from the returned cached object, preventing an old cached observation from masquerading as the number of all reads in the running process.

What a strong answer covers

  • The companion prints rune,rune,glyph and reads2 without executing SQL or HybridCache.
  • Actual pre-commit rollback preserves source/version1 and the valid cached entry.
  • Commit then removal remains two fallible boundaries; cross-instance coordination is not configured.

Common pitfall

Calling database commit plus a later cache removal one atomic distributed transaction.

Follow-up questions

  1. What should happen if the write committed but cache removal failed?
  2. How would another process discover or expire its stale entry?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions