Production engineering
Reveal answer and reasoning
A practical design keeps source reads repeatable, treats per-instance coalescing as an optimization and defines separate timeout and cancellation ownership for each waiter and the shared fill. If duplicate work across processes is unacceptable, introduce a dedicated coordination protocol with failure and lease semantics rather than assuming a secondary cache supplies it. Distinct keys still need their own admission budget so a stream of unique misses cannot create unlimited expensive operations.
The package documents that factory cancellation reflects all callers abandoning the shared operation; canceling one waiter is a different event from canceling every participant. Distinct keys can legitimately start distinct factories. Other HybridCache instances, including instances in another process, do not inherit this owner's coordination even if a secondary store were shared. Neither a one-minute expiration nor RemoveAsync makes source data and cached data one transaction.
The sample's ordinary Task companion is even narrower: it assumes serialized access and never retries a failed or canceled pending task. Keep each limitation attached to the component that actually owns it.
A useful conclusion names the actual package version, one instance, one key, observed factory count and response generations. It does not claim a universal latency improvement or a cluster-wide lock. The companion establishes shared Task identity under serialized calls; the HTTP experiment establishes package behavior for the bounded external fixture. A senior explanation then asks whether factories are safe to repeat, how failed fills are handled and what source consistency the caller needs.
Those questions guide an appropriate cache policy without converting an in-process optimization into a guarantee about external effects, cross-process recovery or coordinated invalidation.
What a strong answer covers
- A practical design keeps source reads repeatable, treats per-instance coalescing as an optimization and defines separate timeout and cancellation ownership for each waiter and the shared fill.
- The package documents that factory cancellation reflects all callers abandoning the shared operation; canceling one waiter is a different event from canceling every participant.
- A useful conclusion names the actual package version, one instance, one key, observed factory count and response generations.
Common pitfall
The package documents that factory cancellation reflects all callers abandoning the shared operation; canceling one waiter is a different event from canceling every participant. Distinct keys can legitimately start distinct factories. Other HybridCache instances, including instances in another process, do not inherit this owner's coordination even if a secondary store were shared. Neither a one-minute expiration nor RemoveAsync makes source data and cached data one transaction. The sample's ordinary Task companion is even narrower: it assumes serialized access and never retries a failed or canceled pending task. Keep each limitation attached to the component that actually owns it.
Follow-up questions
- How would a stream of unique cache keys defeat same-key coalescing, and where would you place a separate source-work budget?
- Why can a later clean cache reset produce generation2 without proving that the previous miss ran two factories?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.