Если нужна гарантия записи — пиши сразу в БД и кэш (write-through). Если можно рискнуть — write-back (кэш сам синхронизируется). И не забудь про TTL.
Писать в кэш как в основное хранилище — путь к потере данных. Если хочется ускорить процесс, то используй write-behind (сначала кэш → потом база) и проверяй TTL.
Частые ошибки студентов
Шардирование ≠ панацея
Не кидайся сразу делить базу на шарды. Сначала оптимизируй запросы, индексы и проверь через EXPLAIN ANALYZE. Часто проблема не в масштабе, а в кривом запросе.
Пример из практики: запрос может тупить из-за того, что база игнорила индексы — оказалось, надо было переписать условие.
Горячие шарды из-за плохого распределения
Избегай шардирования по географическим признакам (например, городам) из-за дисбаланса нагрузки.
Используй виртуальные шарды. Виртуальные шарды случайно распределяются по кольцу хеширования, что снижает риск перекоса при добавлении/удалении нод. Например, 1000 виртуальных шардов на физический.
Кэш без прогрева может выстрелить в проде
Если после деплоя кэш пустой, система будет тормозить. Прогрей его заранее (cache warming) или используй статистику популярных запросов.
Заведи воркера, которые обновляют данные на основе статистики
Базы в кубере — плохая идея
Kubernetes не для stateful-сервисов (баз данных). Они могут «умереть» в любой момент, а восстановление — боль.
Неправильный выбор БД
MongoDB для переписок → антипаттерн: реляционная БД лучше для JOIN и сортировок
Графовая БД для простых связей → избыточность (SQL-таблиц достаточно)
Общие советы
Хранение данных
«Горячие» данные (активные посты) храни в Redis или PostgreSQL
«Холодные» данные (архив) — в S3. И да, поиск по архиву будет медленным — это норма
Тестируй на падения: Что будет, если очередь упадет? А если кэш переполнится? Проверяй edge cases.
Документируй выбор: Почему взял MongoDB, а не PostgreSQL? Зафиксируй решение, чтобы через месяц не гадать.
Не усложняй: Часто простое решение (как реляционная БД) работает лучше «модного» (графовой БД).