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.
Read 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.
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 synthetic coverage checker stores nonoverlapping sorted integer address ranges with a service label. Explain a logarithmic lookup for an address, and how you would test gaps and exact endpoints.
Read model answer +
Binary-search for the range with the greatest start not exceeding the address, then verify that the address is within that range's end. Finding a predecessor alone does not prove coverage.
Work through it
Specify inclusive or half-open endpoints and validate sorted, nonoverlapping ranges when loading configuration. Reject ambiguous overlaps rather than selecting an arbitrary service.
Use a half-open search over starts to locate the first start greater than the address, then inspect its predecessor if one exists.
Test empty configuration, an address before the first range, both boundaries, an internal gap, and an address after the final range. Include a single-address range.
Tradeoffs to discuss
Static sorted arrays offer compact logarithmic reads; frequent range updates may favor an ordered structure with stronger update support.
Common pitfalls
Returning the predecessor label without checking its end incorrectly fills coverage gaps.
Mixing endpoint conventions creates off-by-one errors at neighboring ranges.
