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.