Моменты, которые затрагивают хранение (базы данных, кеши), будем разбирать детально на неделе, посвященной БД
Частые ошибки
- Не выделяешь домены сразу. Без этого проектирование превращается в кашу из кубиков и стрелочек. Домены (личный кабинет, подписки, посты, нотификации) — это основа. Разделяй их до того, как рисуешь архитектуру.
- Выбираешь технологии «потому что». Почему Kafka, а не RabbitMQ? Почему Redis, а не Memcached? Кратко аргументируй свой выбор.
- Лепишь всё в один сервис. Посты, комментарии, лайки — это разные домены! Пихать их в одну базу — гарантировать проблемы с нагрузкой и отказоустойчивостью.
- Углубляешься в детали раньше времени. Сначала рисуешь общую схему (клиент → API Gateway → сервисы), потом детализируешь. Иначе утонешь в мелочах.
- Забываешь про флоу данных. Нарисовал стрелочку от сервиса А к Б? Объясни, что по ней передаётся, как обрабатывается и что делать, если Б упал.
- Шардируешь базу до оптимизации. Сначала индексы, партиционирование, кэши, реплики. Шардинг — это крайний вариант, а не первый.
Главные советы для работы и собесов
- Говори про компромиссы (в англ литературе trade-offs). На собесе любят вопросы вроде: «Почему не выбрали X?». Отвечай: «Рассмотрели X, но Y лучше из-за...».
- Кэш ≠ кэш. Локальный кэш (в памяти приложения) быстрый, но не синхронизирован. Общий кеш (Valkey/Redis) — надёжнее, но сложнее. Выбирай по сценарию.
- Фоллбэки — твой друг. Если некритичный сервис упал, то показывай заглушку или данные из кэша. Никто не любит «500 Internal Server Error».
- Считай нагрузку и хранение. Сколько пользователей? Какой RPS? Сколько данных планируется? Без цифр архитектура — это фантазии.
- Рисуй на собесе. Не стесняйся схематично изобразить компоненты на доске. Так интервьюер поймёт, о чём ты.
- Не все интервьюеры — гуру. Если на собесе спросили про конкретный стек (типа «какой load balancer?»), а ты не в теме — говори концептуально. Google так вообще запрещает тыкать в технологии