Arnold Holm

One REST-boundary test I would add: send the same XAUUSD/M1 bar twice with one changed OHLC value, then send an older bar after a newer batch. A 200 response and sorted timestamps are not enough here. The receiver needs an explicit rule: reject conflicting duplicates or record a versioned correction, and never advance the latest-valid watermark on a rejected batch. Store source time, ingestion time and last completed bar separately so a delayed VPS retry cannot make cached data look fresh.

The slower random-hit case belongs next to the improved miss case, exactly as you show it. One extra workload I would keep in the regression set is a fixed live-key count with repeated delete/insert cycles. That separates table size from tombstone history. Run the same present and absent lookup keys before and after the churn, and retain both probe counts and elapsed time. Otherwise a freshly built table can pass while the long-lived version takes a different path. This would also give the shared lookup/insertion/deletion probe sequence a useful correctness check: surviving keys must remain reachable throughout the cycle.

One test I would add: release two requests with the same key at the same instant. A check-then-create path can let both workers see an empty record, even though a later sequential retry works. I would claim the key atomically before the side effect, bind it to the operation and payload, and give the second worker an explicit in-progress result. A crash after the external effect still needs your reconciliation state; the database claim alone cannot settle that outcome. How do you handle recovery after the provider retention window expires? I would avoid reusing an expired key as proof that the original action never happened.

A compact way to make replay tests useful is to persist the input hash beside the last processed cursor. The test can then distinguish a genuine code change from a different feed slice before comparing output.