Кеширование
Инвалидация кэша: воспроизведи и закрой гонку
Читать про гонку set-after-delete — не то же самое, что заставить её срабатывать по требованию, а затем убить. Построй маленький cache-aside-сервис, загони параллельных читателя и писателя в гонку, пока не увидишь устаревшие данные на каждом прогоне, затем примени фиксы юнита, пока процент несогласованности не упадёт в ноль — с доказательством на каждом шаге.
Преврати модель консистентности юнита в воспроизводимый стенд: спровоцируй гонку set-after-delete и синхронизированную TTL-стампиду, затем закрой каждую правильным рычагом (double-delete или лизы, jitter, выбранная стратегия записи) и проверь числами до/после, а не рассуждением.
Построй cache-aside-сервис поверх Postgres + Redis, воспроизведи гонку set-after-delete и TTL-стампиду детерминированно, затем закрой обе и докажи фиксы измеренными числами процента несогласованности и нагрузки на origin — до и после.
- Таблица до/после: процент несогласованности set-after-delete (база против double-delete против лиз), измеренный на одном прогоне стенда — не оценённый.
- Таблица до/после для стампиды: пик origin qps на истечении с фиксированным TTL против jitter + single-flight, в одном сценарии прогрев-и-истечение.
- Доказательство, что delete-on-write держит TTL-страховку: симулируй упавший DEL (пропусти его) и покажи, что TTL ограничивает окно несвежести, затем покажи, что удаление TTL оставляет значение устаревшим бесконечно.
- Абзац-разбор, утверждающий для каждой аварии, какой рычаг её закрыл и почему ты выбрал его вместо альтернатив (например double-delete против лиз против write-through) с учётом стоимости и требования read-your-writes.
- Добавь on-call-runbook: как распознать репорт set-after-delete (правка откатывается на ~TTL, не воспроизводится локально), шаги триажа и лестницу приоритета фиксов (сначала jitter и TTL-страховка, затем double-delete/лизы, затем write-through).
- Добавь write-behind-вариант и намеренно убей узел до асинхронного сброса, чтобы продемонстрировать, как окно durability теряет выглядящую закоммиченной запись — затем покажи durable-очередь, закрывающую его.
- Добавь нормализацию cache key: запрос с шумными параметрами (utm_*, порядок параметров) и покажи обвал hit rate, затем исправь ключ, чтобы включал только влияющие на ответ параметры, и измерь восстановление hit rate.
- Добавь probabilistic early refresh поверх jitter и покажи, что он перестраивает горячие ключи до истечения, выравнивая подъём origin сильнее, чем jitter в одиночку.
Это цикл, который ты запустишь в каждом реальном инциденте консистентности кэша: воспроизведи аварию детерминированно, прежде чем верить любому фиксу, выбери рычаг под ситуацию (jitter и TTL-страховка для стампид и пропущенных purge, double-delete или лизы для гонки set-after-delete, write-through, когда read-your-writes не обсуждается) и проверь числами до/после под идентичной нагрузкой. Сделав это однажды на игрушечном сервисе, превращаешь продакшен-версию — где устаревшие данные это откатившийся профиль пользователя — в мышечную память.