Как мы обслуживаем 5 млрд карточек в сутки с задержкой меньше 1 мс

https://habr.com/ru/articles/942274/

Классическая история, ребята столкнулись с проблемой выросшего стартапа — PHP-монолит с миллионами товаров начал задыхаться под нагрузкой. Решили вынести самые нагруженные части в отдельные сервисы. Один из них — сервис карточек товаров с жесткими требованиями: 99% ответов за 30 мс, 300к RPS в пике. О нём и пойдёт речь.

Что сделали:

— Двухуровневая архитектура с горячим и холодным хранилищами

— Горячий кеш в памяти с алгоритмом вытеснения 2Q (а не LRU/LFU): защита от sequential scan.

— Сегментирование для многопоточности: разбили кеш по типам моделей данных

— Инвалидация через Redis Streams: декораторы на репозиториях отправляют события об изменениях

— Прогрев после деплоя: собирают статистику популярных товаров и греют только их (старт занимает несколько минут)

Результат: медиана 348 микросекунд при 5 млрд запросов в сутки. Для одной карточки нужно 35 обращений к кешу и данные из 130 сущностей.

————

В подобных статьях меня всегда радует, когда автор честно пишет про проблемы и костыли (неконсистентность между слоями, проблема прогрева).

Немного смущает выбор 2Q "по непонятным причинам" — это же архитектурное решение, а не цвет кнопки 🦄

В целом — must read для тех, кто интересуется высоконагруженными системами.

#article #highload #cache