Кеширование
ETag: пусть ревалидация переживёт балансировщик
Читать про баг поюнитного ETag — не то же, что смотреть, как он рушит твой график egress. Подними небольшое API с несколькими репликами, добавь ETag наивно, воспроизведи регрессию «сплошные 200» за балансировщиком, затем почини содержательным тегом и докажи выигрыш трафика реальными числами.
Преврати ментальную модель юнита в воспроизводимый цикл: реализуй conditional request корректно, продемонстрируй сбой, прячущийся в одно-серверной разработке, почини в корне и проверь долю 304 и сэкономленные байты измерениями до/после.
Построй небольшое JSON API, отдающее редко меняющийся ресурс, добавь conditional request на ETag, воспроизведи поюнитный сбой 304 между несколькими репликами за балансировщиком, почини содержательным валидатором и докажи экономию трафика числами до/после.
- Таблица до/после: доля 304, суммарные переданные байты за N опросов и байты на опрос для неизменного контента — измеренные под одной нагрузкой против установки с несколькими репликами, а не на одном сервере.
- Захваченный лог обмена (curl -v или DevTools), показывающий, что после фикса один контент даёт согласованный ETag между репликами там, где раньше он различался.
- Обработка conditional корректна: 304 не несёт тела, реальное изменение контента даёт 200 с новым ETag, а клиент подхватывает новую версию на следующем опросе.
- Короткий разбор: почему исходный тег был локальным для узла, почему содержательный тег устойчив к балансировщику и что здесь реально сэкономил 304 (байты, а не круговой обход).
- Добавь обработку weak vs strong: выдавай сильный ETag для identity-тела, варьируй его по Content-Encoding при gzip и продемонстрируй If-Range-запрос, корректно отказывающий в частичном ответе при слабом валидаторе.
- Выдавай Last-Modified рядом с ETag и сконструируй субсекундное двойное обновление, обманывающее If-Modified-Since до устаревшего 304, пока If-None-Match остаётся корректным, — доказывая секундную слепую зону.
- Поставь Cache-Control max-age перед ETag и покажи композицию: клиент вообще пропускает запрос, пока свеж, затем откатывается к ревалидации, фиксируя число запросов для каждой фазы.
- Добавь on-call-раннбук: как заметить регрессию «сплошные 200» на дашборде egress/доли 304, чек-лист поюнитного ETag (inode, дрейф mtime, состояние процесса, сжатие) и однокомандную проверку по проводу на согласованность между репликами.
Это цикл, который ты будешь проходить на любом реальном инциденте ревалидации: реализуй рукопожатие conditional корректно, воспроизведи поюнитный сбой, который прячет одно-серверная разработка, почини, сделав ETag чистой функцией контента, чтобы каждая реплика совпадала, и проверь числами до/после долю 304 и сэкономленные байты под одной нагрузкой. Сделав это раз на игрушечном API, ты делаешь продовую диагностику — «почему доля 304 рухнула после масштабирования?» — мгновенной.