Почему secondary иногда быстрее primary
В части событий secondary feed приходит быстрее primary. Как охарактеризовать эти случаи и найти причину?
Короткий ответ
Нужно выделить пары, где secondary быстрее, и сравнить их с нормальными парами по времени, burst-rate, exchange timestamp, цене, количеству событий и задержке primary.
Полный разбор
Сначала строим признак secondary_faster = local_secondary < local_primary для matched events. Дальше не надо сразу гадать причину: нужно сравнить эти строки с обычными по нескольким срезам.
Полезные срезы: время дня, интервалы с большим числом тиков, latency primary, latency secondary, конкретные инструменты, price anomalies, пропуски в primary, out-of-order события. Если secondary быстрее только во время bursts, вероятная причина - primary начинает задерживаться при высокой нагрузке. Если это происходит в конкретные минуты, возможен сетевой или pipeline incident.
В production это превращается в мониторинг: доля secondary_faster по окнам, p95 latency по feed, missing paired events, zero/invalid price и alert на резкие отклонения.
Теория
Это root-cause analysis: сначала строится подвыборка аномалий, затем ищутся признаки, по которым она статистически отличается от нормального режима.
Типичные ошибки
- Сразу объяснять все "сетевой проблемой" без срезов.
- Не сравнить anomalous subset с baseline subset.
- Не смотреть bursts и time windows.
Как отвечать на собеседовании
- Формулируй как slice-and-compare.
- Назови гипотезу про bursts, но подчеркни, что ее надо проверить.