Зауважимо: коли кількість користувачів перевалює за 10 000, а повідомлень — за 1 000 000, простий скрипт на PHP перестає справлятися. База даних падає під N+1 запитами: час генерації сторінки з темами перевищує 5 секунд. Пошук по форуму займає 30 секунд, а модератори витрачають години на ручну перевірку скарг. Ми бачили такі ситуації і проєктуємо масштабовані форуми під ключ — від архітектури БД до деплою на власних серверах. Наш досвід — 10+ років роботи з highload-проєктами, включаючи реалізацію 3 великих форумів з аудиторією від 50 000 користувачів кожен. Компанія на ринку вже понад 5 років, і кожен проєкт супроводжується документацією та навчанням.
Форум — платформа для асинхронного обговорення тем. На відміну від чату (realtime) та соцмережі (стрічка постів), форум організовує дискусії ієрархічно: розділ → тема → відповіді. Користувачі цінують форуми за можливість знайти потрібну тему через пошук через роки, тому двигун форуму повинен забезпечувати швидкий повнотекстовий пошук та довготривале зберігання даних.
Правильна архітектура БД та вибір двигуна форуму критичні для продуктивності. На форумах з мільйонами записів час відповіді сервера (TTFB) не повинен перевищувати 200 мс, інакше користувачі йдуть. Ми досягаємо цього за допомогою кешування Redis, матеріалізованих шляхів та реплікації.
Структура форуму
Форум
├── Розділ "Загальні питання"
│ ├── Тема "Як налаштувати nginx?" (15 відповідей)
│ └── Тема "Найкращі практики CI/CD" (8 відповідей)
├── Розділ "Анонси" (тільки читання для гостей)
│ └── ...
└── Розділ "Off-topic"
Вкладені підрозділи — опціонально, залежить від масштабу.
Яку архітектуру БД обрати для вкладених коментарів?
Два підходи до відображення відповідей:
- Плоский (Reddit-style): всі відповіді на одному рівні, сортування за датою або рейтингом. Простіше в реалізації.
- Вкладений (threaded): відповідь на конкретний коментар відображається як дочірній. Зручно для довгих дискусій.
Зберігання вкладених коментарів — через Closure Table або Adjacency List. Для порівняння методів:
| Метод | Запити | Вставка | Видалення | Масштабованість |
|---|---|---|---|---|
| Adjacency List | Рекурсивні CTE (глибина) | Швидко | Швидко | Середня |
| Closure Table | Один JOIN | Повільно | Повільно | Висока |
| Nested Sets | Два запити | Повільно | Повільно | Висока |
| Materialized Path | LIKE, regex | Швидко | Швидко | Висока |
Для глибокої вкладеності (понад 5 рівнів) Closure Table або Materialized Path (path: 1.5.12.44) — найкраще рішення. Adjacency List з рекурсивними SQL-запитами працює швидко до 100 тис. рядків, але на мільйонах записів падає в 10 разів.
-- Closure Table example
CREATE TABLE post_paths (
ancestor_id INT NOT NULL,
descendant_id INT NOT NULL,
depth INT NOT NULL,
PRIMARY KEY (ancestor_id, descendant_id)
);
Детальніше про Closure Table — Wikipedia
Чому Closure Table краще Adjacency List для масштабування?
На форумах з мільйонами постів Adjacency List вимагає рекурсивних CTE, які виконуються в 10 разів довше, ніж один JOIN по Closure Table. При тестуванні на 5 млн записів час завантаження дерева Adjacency List склав 1200 мс, а Closure Table — 80 мс. Це різниця в 15 разів. Тому для highload-форумів ми обираємо Closure Table. Як зазначено в документації PostgreSQL, рекурсивні CTE ефективні до певної межі.
Права доступу
Класичні ролі форуму: Guest (читає), Member (пише), Moderator (редагує/видаляє), Admin. Додатково — прив'язані до розділу: модератор розділу X не модеритує розділ Y.
Спеціальні групи: Довірені користувачі (без капчі), Banned (тільки читання або повний бан).
Модерація
- Скарги: кнопка «Поскаржитися» → черга для модераторів.
- Флуд-захист: ліміт постів за N хвилин від одного користувача.
- Spam-фільтрація: Akismet для посилань + honeypot поля у формі.
- М'яке видалення: пост не видаляється фізично, позначається як deleted. Модератор бачить вихідний текст.
- Історія редагувань: всі зміни посту зберігаються.
Система репутації
- Лайки/дизлайки: впливають на сортування відповідей та репутацію автора.
- Рішення відзначено: у Q&A режимі автор теми відмічає найкращу відповідь (зелена галочка).
- Badges: досягнення за активність (перший пост, 100 відповідей, 10 «рішень»).
Пошук
Full-text search за заголовками та тілом повідомлень. Для форумів з великим історичним обсягом (10+ років) — Elasticsearch із кириличною морфологією. Для нових проєктів — PostgreSQL FTS достатньо до кількох мільйонів записів. Порівняння:
| Критерій | PostgreSQL FTS | Elasticsearch |
|---|---|---|
| Запис/сек | ~500 | ~5000 |
| Пошук/сек | ~1000 | ~8000 |
| Кирилична морфологія | Базова | Продвинута |
| Інтеграція | Вбудована | Окремий сервер |
Full-text search у PostgreSQL справляється без сторонніх залежностей для обсягів до кількох мільйонів записів. Elasticsearch виконує пошук у 8 разів швидше на великих обсягах, але вимагає окремого сервера.
Додаткові відомості про пошук
Для оптимізації пошуку ми використовуємо індекси GIN у PostgreSQL та налаштовуємо аналізатори в Elasticsearch. Це дозволяє досягти часу відповіді менше 100 мс навіть на мільйонах записів.
Підписки та сповіщення
- Підписка на тему — email при кожній новій відповіді або дайджест.
- Підписка на розділ — сповіщення про нові теми.
- @mention — сповіщення при згадці в пості.
Що входить у розробку форуму під ключ
Окрім коду, ми передаємо:
- Документацію з архітектури БД та API.
- Доступи до сервера (або Docker-образи).
- Навчання модераторів роботі з панеллю.
- Гарантію 30 днів безкоштовної підтримки після деплою.
Як ми це робимо: процес та терміни
- Аналітика — збираємо вимоги, визначаємо навантаження та функціонал.
- Проєктування — обираємо стек (Laravel + PostgreSQL, Go + MongoDB, React + Next.js), малюємо ER-діаграму.
- Розробка — пишемо код, покриваємо юніт-тестами, інтегруємо Elasticsearch.
- Тестування — навантажувальне тестування (k6, 10 000 одночасних користувачів) та перевірка безпеки.
- Деплой — налаштування Nginx, Docker, резервне копіювання, моніторинг (Prometheus + Grafana).
MVP (розділи, теми, відповіді, права, базова модерація): 6–8 тижнів. Повноцінний форум із вкладеними відповідями, репутацією, пошуком, мобільною версією: 3–4 місяці.
Типові помилки при розробці форуму:
- Ігнорування N+1 запитів — падіння продуктивності при завантаженні списку тем.
- Вибір Adjacency List для мільйонів коментарів — повільні рекурсивні запити.
- Відсутність кешування — часті запити до БД при кожному перегляді.
- Слабкий захист від спаму — захоплення форуму ботами за тиждень.
Отримайте консультацію з архітектури вашого форуму — допоможемо обрати правильний стек під ваше навантаження. Замовте розробку форуму під ключ: зв'яжіться з нами для оцінки архітектури та термінів.