Что выбрать для кэша рядом с базой данных: Redis, RabbitMQ или Kafka?

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

Видите ли вы подвох. Вопрос сформулирован так, будто три инструмента взаимозаменяемы, а на деле это три разных класса систем, и только один из них кэш. Проверяют, назовёте ли вы разницу и не выберете ли по популярности.

Как отвечать

Сначала развести понятия. Redis это хранилище в памяти с доступом по ключу, подходит под кэш. RabbitMQ это брокер сообщений: маршрутизация, подтверждения, очереди задач, сообщение уходит потребителю и исчезает. Kafka это распределённый лог: события хранятся, читаются по смещению, их можно перечитать. Ни у брокера, ни у лога нет операции «дай значение по ключу», поэтому как кэш они не работают.

Значит выбор Redis, и дальше стоит показать, что вы понимаете цену решения:

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

Про Python добавить, что клиент держит пул соединений, а для асинхронного кода берут асинхронный вариант того же клиента. И отметить, что кэш в памяти процесса живёт отдельно в каждом рабочем процессе и на нескольких воркерах даёт расхождение ответов.

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

Повторяют за источником, что Redis не умеет сохранять данные. Умеет: снимки и журнал операций. Другое дело, что источником правды его делать не стоит, и это надо объяснять именно так.

Второе: кладут значения без срока жизни и без плана инвалидации. Пользователь получает устаревшие данные, а найти это тяжело, потому что в базе всё правильно.

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