ORIGINAL COMPANY-CONTEXT PRACTICE
Invalidate a customer-plan cache
Original practice scenario inspired by Deutsche Telekom AG's public business context; this is not a reported interview question or a description of its internal systems. A fictional telecom portal caches customer plan details. Changes can arrive through several sales channels, and an update event may be delayed or delivered twice. Design cache behavior that limits stale plan displays.
Written for independent practice using company context; this is not a verified question from a company interview.
A REASONED APPROACH
Model answer.
Use versioned customer-plan state and define a freshness bound. Event invalidation improves responsiveness, but a bounded expiry or version check is still needed when events are delayed or lost.
Work through it
- Publish a change event through a transactional outbox after updating the authoritative plan. Include customer identity and a monotonic plan version.
- Ignore older events and invalidate or replace cache entries only when the version warrants it. Prevent a slow old read from overwriting a newer cached version.
- Use read-through refresh with request coalescing and bounded TTL. Test event reorder, duplicate delivery, missed invalidation, and concurrent updates across channels.
Tradeoffs to discuss
- Short TTLs reduce staleness but increase origin load. Critical billing actions should consult authoritative state rather than trusting a display cache.
Common pitfalls
- Deleting a key once does not prevent a racing stale writer from repopulating it.
- Cache availability and data freshness are separate service properties.