Низкое лейтенси и кеш, или снова про прагматизм.

Как-то само собой в наших головах устоялось как факт – хочешь низкое лейтенси, используй кеш а не БД.
Но время идет, и кеши и БД развиваются друг к другу на встречу. Кеши теперь от БД не отличишь, а БД содержат кучу всевозможных in-memory кешей.

Современные реляционные БД держат горячие записи в in-memory кешах. Движок БД сам решает что есть горячие записи, но эффективная схема данных и правильно настроенная БД будут давать лейтенси не выше чем кеши вроде Redis у самых важных запросов.

Реляционные БД обычно не поддерживают шардирование из коробки (масштабирование операций записи), MySQL поддерживает но с кучей исключений.
Из коробки! - не надо тут про франкенштейнов поверх ядра вроде Postgres Pro и Тантор.
Кеши шардирование обычно поддерживают. Поэтому когда операций записи слишком много, кеши на удивление помогают, но не с производительностью как это принято считать, а с масштабированием 😁
А когда у нас в запасе NoSQL БД с часто неограниченным масштабированием, то и нужды в кеше получается что и нет.

Нужда остается, когда типы запросов и данные очень уж подходят под функции кеша, но кеш тут выступает как NoSQL БД полнофункциональная а не старый добрый кеш.

Shopify убрал Redis и оставил MySQL и легко справился с их сумашедшей нагрузкой 😆
И это все не супер новая какая-то история, уже лет 10 как эти идеи актуальны. Но я по прежнему встречаю очень популярное заблуждение - хочешь низкое лейтенси, используй кеш а не БД.

Недавно видел одну как бы микросервисную архитектуру, где все сервисы обращаются к одному инстансу PostgreSQL 😄
Нагрузка постоянно растет, но БД ее не замечает. Как такое возможно?
А потому что эту БД со всех сторон обложили Redis вроде как кешом, а на самом деле каждый инстанс Redis – это отдельная NoSQL БД.
Меня улыбнула эта находка, но расстроило что за долгие годы я первый кто это заметил 🤣

Поэтому давайте будем прагматичными а старые верования пора обновить 😜