Насколько данные в базе отставали от реальности?

Что проверяют

Мерили ли вы свежесть данных или отвечаете на глаз. Вопрос уточняющий: интервьюер зацепился за вашу историю про синхронизацию и проверяет, знаете ли вы, из чего складывается отставание и какому требованию оно должно было удовлетворять.

Как отвечать

Сначала назовите метрику, потом величину. Метрика это разница между временем события в источнике и моментом, когда запись стала видна потребителю. Считается она прямо в базе через max(now() - event_time) и выносится в мониторинг, а не вспоминается по жалобам пользователей.

Дальше разложите отставание на слагаемые:

• период запуска синхронизации: при расписании раз в четверть часа отставание в худшем случае уже не меньше этого интервала;
• длительность самого прогона плюс повторы после ошибок источника;
• лаг реплики, если читают не с мастера: в PostgreSQL он виден через pg_last_xact_replay_timestamp();
• время жизни кеша в приложении, которое складывается со всем предыдущим.

Закончите тем, укладывалось ли это в потребность. Витрине сутки не мешают, балансу пользователя мешают сразу. Если требований к свежести не было, честно скажите, что пришли к ним после первого инцидента, и опишите, что поменяли: метрику, алерт на её рост, отметку «данные актуальны на» в интерфейсе.

Где спотыкаются

Отвечают «почти в реальном времени». Это не ответ, а уход: задержка есть у любого конвейера, и следующий вопрос будет ровно про то, чем вы её измеряли.

Второе: называют круглую долю сокращения устаревших записей, взятую из шаблона рассказа. Такие цифры разваливаются на первом же уточнении, откуда взята база сравнения и кто считал.

Третье: путают виды отставания. Свежесть конвейера, лаг реплики и время жизни кеша это три разные величины, и жалоба на отставшую базу нередко оказывается чтением с реплики сразу после записи. Ещё чаще свежесть меряют по своей же колонке времени загрузки, которая по определению не видит задержку источника.