Главное Авторские колонки Вакансии Вопросы
31 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Архитектура маркетплейса на 100 000+ товаров: кэширование, балансировка и выбор БД — наш опыт

В этой статье я расскажу, как мы перепроектировали архитектуру для маркетплейса недвижимости с каталогом более 100 000 объектов. Исходные данные: API отвечал за 200 мс, поиск работал на базе MySQL с LIKE-запросами, пиковая нагрузка — 10 000 пользователей одновременно.
Мнение автора может не совпадать с мнением редакции

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

В этой статье я расскажу, как мы перепроектировали архитектуру для маркетплейса недвижимости с каталогом более 100 000 объектов. Исходные данные: API отвечал за 200 мс, поиск работал на базе MySQL с LIKE-запросами, пиковая нагрузка — 10 000 пользователей одновременно. После наших изменений: время ответа API — 15 мс, поиск — 50 мс, система держит 10 000 пользователей без деградации.

Оценка нагрузки и требований

Прежде чем писать код, мы провели анализ:

  1. Чтение/запись: 90% чтения (каталог, карточки, поиск), 10% записи (бронирования, заявки).
  2. Пиковый RPS (запросов в секунду): 50 000 на чтение, 5 000 на запись.
  3. Сезонные пики: выходные дни, вечерние часы — прирост до +30%

Эти цифры определили наш выбор инструментов.


Кэширование — первый рубеж обороны

Мы внедрили многоуровневый кэш:

  1. CDN (CloudFront) для статики: изображения, CSS, JS. Это снизило нагрузку на origin-серверы на 70%.
  2. Микрокэширование на Nginx — для страниц поиска и каталога (TTL 1–5 секунд). Пример конфига:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:100m inactive=60s; proxy_cache_key "$scheme$request_method$host$request_uri"; proxy_cache_valid 200 302 5s;

Это позволило отдавать динамические страницы без пересчёта на бекенде.

  1. Redis Cluster (6 нод, 32 ГБ ОЗУ каждая) — для кэширования JSON-ответов API, сессий пользователей, вычисляемых рейтингов и агрегатов. Использовали стратегию Cache-Aside для чтения и Write-Through для обновлений.

Результат: время ответа API упало с 200 мс до 15 мс, загрузка CPU на бекенде сократилась на 60%. Подробнее результаты можно изучить в нашем кейсе.

Балансировка и горизонтальное масштабирование

Мы выбрали Nginx Ingress как балансировщик в Kubernetes. Настроили health checks, retries, rate limiting (не более 100 запросов в секунду с одного IP). Приложения сделали stateless — сессии хранятся в Redis, поэтому можно добавлять поды без привязки. Для авто-масштабирования использовали HPA (Horizontal Pod Autoscaler) на основе CPU и длины очереди запросов.

В пиковые часы система автоматически разворачивала до 10 подов, что позволяло держать 10 000 одновременных пользователей с задержкой менее 100 мс. Без авто-масштабирования нам пришлось бы закупить в 3 раза больше ресурсов.

Выбор баз данных — никакого компромисса

Мы применили полиглотный подход:

  1. PostgreSQL — основная БД для транзакционных данных: пользователи, заказы, объекты недвижимости. Использовали партиционирование по месяцам и GIN-индексы для полнотекстового поиска по описаниям (на случай, если Elasticsearch недоступен).
  2. Elasticsearch — поисковый движок. Индексируем 100 000 записей, поддерживаем синонимы, фасеты, релевантность. Время поиска — 50 мс (это критично для UX).
  3. ClickHouse — для аналитики: храним историю просмотров, кликов, конверсий. Строим отчёты для владельцев бизнеса за считанные секунды по миллионам записей.
  4. Redis — кэш и брокер очередей (для фоновых задач).

Мы разделили потоки: запись идёт в PostgreSQL, чтение — через Elasticsearch и ClickHouse. Для распределения чтения настроили реплики master-slave.


Мониторинг и трассировка

Настроили Prometheus + Grafana для сбора метрик по каждому эндпоинту: RPS, латентность (p50, p95, p99), ошибки, использование CPU/RAM. Jaeger для распределённой трассировки — это позволяет видеть полный путь запроса и находить узкие места (например, медленный внешний вызов). Алерты в Slack при превышении порогов.

Заключение

Нет универсального решения, но есть проверенные паттерны: кэшируйте всё, что можно, дублируйте данные без страха перед избыточностью, и выбирайте БД под конкретную задачу. Мы не переписывали архитектуру ни разу за полгода после запуска — она выдержала 3-кратный рост трафика.

Если ваш продукт начинает «тормозить» — это сигнал, что пора заняться архитектурой. Мы предлагаем архитектурный аудит: за 2–4 недели мы проанализируем вашу нагрузку, предложим решения и поможем избежать дорогих ошибок.

LP Agency — мы строим системы, которые растут вместе с вашим бизнесом.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.