Когда Toplix начнёт расти, я бы не переносил всё сразу на дорогую инфраструктуру. Для него хорошо подходит постепенное разделение по нагрузке.
Сейчас ваша архитектура уже удачная: основной Toplix отдельно, Relay отдельно. На старте этого достаточно. Для Краснодарского края и первых пользователей сервер уровня 4 vCPU / 8 ГБ RAM / NVMe 80–160 ГБ вполне разумен для WordPress, API и базы. Relay можно оставить небольшим — примерно 1–2 vCPU / 2–4 ГБ RAM.
Когда появится активная аудитория и «Обстановка сейчас», я бы разделил систему уже на три части:
- Web/API Toplix — 4–8 vCPU, 8–16 ГБ RAM;
- отдельная база MySQL/MariaDB — 4–8 vCPU, 16 ГБ RAM, быстрый NVMe;
- чат/realtime — отдельный небольшой сервер 2–4 vCPU, 4–8 ГБ RAM.
Плюс Redis для кеша и быстрых временных данных. Карты, карточки, каталог и поиск не должны каждый раз нагружать базу одинаковыми запросами.
Когда Toplix выйдет уже на всю Россию и появятся десятки тысяч активных пользователей в день, схема станет примерно такой:
Балансировщик → 2–3 сервера Toplix/API → отдельная БД → Redis → отдельный realtime/chat → Relay/сборщики источников.
Тогда один сервер можно обновлять или даже потерять, а сайт продолжит работать.
Для условных масштабов я бы ориентировался примерно так:
| Нагрузка | Архитектура |
|---|---|
| до ~5–20 тыс. посещений/сутки | 1 хороший VPS Toplix + отдельный Relay |
| ~20–100 тыс./сутки | Web отдельно + БД отдельно + Redis + чат отдельно |
| 100 тыс.+/сутки | несколько Web/API серверов + балансировщик + мощная БД |
| высокая nationwide-нагрузка | кластер, реплика БД, очередь задач, CDN, мониторинг |
Но важнее не само число посетителей, а одновременная нагрузка. Например, 50 000 человек за сутки — не проблема. А 10 000 человек, одновременно открывших карту и живой чат после какой-нибудь новости о дефиците топлива, — уже серьёзная нагрузка.
И именно поэтому будущий чат я бы сразу проектировал так, чтобы его потом можно было вынести из WordPress на отдельный сервис, хотя первую версию можно спокойно запустить внутри нынешнего Toplix.
Для карты тоже есть важный момент: когда будет уже, например, 50–100 тысяч АЗС/ЭЗС по России, браузеру не нужно отдавать весь реестр сразу. Сервер будет возвращать только точки текущего региона/экрана карты и кластеры. Тогда даже огромная база останется быстрой.
То есть Toplix не требует какого-то «суперсервера» на старте. Правильнее построить систему так, чтобы при росте добавлять отдельные узлы, а не однажды переносить огромный монолит.
Я бы для Toplix уже сейчас держал целевую архитектуру такой:
Toplix Web/API → БД → Redis → Chat → Relay → внешние источники
И масштабировать каждый компонент независимо. Это позволит спокойно дойти от Краснодарского края до всей России без полной переделки сервиса.
Нет, сейчас 2–3 сервера вам не нужны.
На старте я бы оставил текущую схему:
1 основной сервер Toplix + 1 отдельный Relay.
Этого достаточно, пока аудитория небольшая и чат только запускается.
Отдельный третий сервер имеет смысл подключать позже, когда появится реальная нагрузка, например:
- чат станет активно использоваться;
- одновременно на сайте будут сотни/тысячи пользователей;
- база начнёт заметно тормозить;
- карта и API начнут создавать нагрузку;
- появится необходимость разделить web, БД и realtime.
То есть сейчас правильнее не усложнять инфраструктуру заранее.
Для старта:
- основной сервер — сайт, API, БД, первая версия чата;
- Relay — внешние источники;
- всё остальное пока не выносить.
А когда нагрузка реально вырастет, первым делом я бы вынес чат/realtime или базу, смотря что начнёт упираться первым.
Так дешевле, проще и надёжнее.
Да, это можно сделать практически незаметно для пользователей — если переходить не «в один день переносом сайта», а поэтапно.
Для Toplix я бы заранее держал такую схему перехода:
- Пока всё работает на текущем основном сервере, поднимаем второй Web/API-сервер как копию Toplix.
- Перед ними ставим reverse proxy / load balancer. Сначала он отправляет 100% трафика на старый сервер — для пользователей ничего не меняется.
- Выносим общие вещи из конкретного сервера: сессии/кеш → Redis, загружаемые файлы → общее хранилище, чтобы оба Web-сервера видели одинаковые данные.
- Базу переносим на отдельный сервер через репликацию: старая БД продолжает обслуживать сайт, новая синхронизируется в реальном времени.
- Затем постепенно переводим трафик: например 5% → 20% → 50% → 100% на новую архитектуру. Если видим проблему — мгновенно возвращаем всё назад.
- Когда убедились, что новая схема стабильна, старый сервер оставляем ещё на несколько дней как резерв, а потом выводим из работы.
Для пользователя в идеале максимум, что он заметит, — ничего. Карта открывается, карточки работают, чат продолжает обновляться.
С будущим чатом ещё проще: его можно сначала запустить внутри WordPress, а потом вынести в отдельный сервис. Мы оставляем тот же API-адрес, например /api/live-status, а внутри меняем, куда этот запрос идёт. Пользовательский интерфейс вообще не меняется.
Для базы я бы делал переход через репликацию, а не через «закрыть сайт, скачать SQL, загрузить SQL». Тогда данные продолжают поступать до самого переключения.
И ещё важная вещь: мы можем подготовить Toplix к такому росту уже сейчас без покупки дополнительных серверов. Нужно просто не делать архитектурных решений, которые привязывают всё к одной машине. Например, будущий модуль «Обстановка сейчас» сразу делать через API и отдельную таблицу, а не жёстко вплетать в шаблон WordPress.
Получится примерно такая эволюция:
Сейчас:
Пользователь → Toplix server → DB
Toplix → Relay → источники
При росте:
Пользователь → Load Balancer → Toplix #1 / Toplix #2 → Redis → DB
→ Chat service
→ Relay
Самое главное — не ждать момента, когда сервер уже задыхается. Мы будем видеть рост заранее по CPU, RAM, времени ответа, количеству одновременных запросов и нагрузке на БД. Когда появятся первые устойчивые признаки нагрузки, тогда добавим второй узел спокойно, а не в аварийном режиме.
То есть нынешнюю инфраструктуру переделывать сейчас не нужно. Но следующие функции Toplix я буду проектировать так, чтобы потом их можно было вынести на отдельные серверы без переписывания всего сервиса.