15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
🔥devmangx&utm_term=phystech">Прими участие в Хакатоне от ИТ-холдинга Т1 в Новосибирске и поборись за призовой фонд 800 000 рублей!XoDefender&utm_term=phystech">
Когда: 23–26 октября
Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, CV, ML или DevOps;
🔹сможешь быть в Новосибирске 26 октября.
Выбери свой кейс:
✴️Цифровой дресс-код: фон, который выделяет вас. Создай локальный ML-модуль сегментации видео и генератор персонализированных фонов.
✴️CodeMetrics: метрики, которые помогают расти. Разработай систему автооценки эффективности команд через анализ Git-метрик.
О кэше:
FE использует LRU-кэш для результатов, которые стримятся обратно.
BE имеет более сложную схему кэширования: L1 — In-Memory LRU, в основном для дедупликации запросов и быстрого получения результатов при нажатии backspace;
L2 — Redis, который хранит «терминальные» результаты (с полностью известной доступностью, ценой и премиум-статусом) с TTL, убывающим экспоненциально в зависимости от длины, премиум-статуса и популярности TLD.
На каждом pod-е запускается свой инстанс SQLite, синхронизируемый при старте, для хранения кэша известных премиум-доменов.
Также используются Bloom-фильтры — сейчас их пять: основной фронтлайновый для доступности на основе Root Zone файлов IANA и несколько дополнительных для известных премиум-данных от операторов реестра.
👉 @BackendPortal
У WebSocket есть собственные механизмы Keep Alive, аналогичные TCP, и называются они PING и PONG.
Основная цель поддерживать соединение активным, проверять, что другая сторона всё ещё на связи. Думаю, что можно отправлять данные inline внутри PING или PONG (хотя сам я этого не пробовал).
Ещё один важный момент. WebSocket может проходить через промежуточные звенья (прокси), поэтому он может растягиваться на несколько TCP-соединений. В результате одного только TCP keep alive недостаточно. Когда отправляется PING, этот WebSocket-фрейм проходит через несколько TCP-соединений и промежуточных узлов, обновляя их.
Очень удобно, что Wireshark умеет расшифровывать TLS и можно увидеть, что происходит, благодаря тому, что Chrome позволяет писать TLS-ключи на диск (переменная окружения SSLKEYLOGFILE).
👉 @BackendPortal
Ручные проверки тормозят релизы? 🐞
Приглашаем на бесплатный вебинар Test IT x Gitflic!
📆 6 октября в 12:00 (мск)
Покажем, как сократить разрыв между кодом, тестами и релизами через интеграцию платформ Test IT и GitFlic. Связка убирает ручные стыковки и собирает в единый процесс цепочку «код → PR → тесты → баг → фикс».
Будет полезен командам разработки и тестирования в сегменте SMB, а также тимлидам и руководителям проектов, которые хотят наладить прямую связку кода и тестов.
Покажем в действии:
▪️ Как Test IT помогает держать под контролем тесты и результаты.
▪️ Что нового в GitFlic Pro и почему это решение удобно для небольших команд.
▪️ Как работает интеграция Test IT + GitFlic Pro от коммита и PR до тест-кейса и баг-репорта.
Спикеры:
🔸 Андрей Черных, ведущий разработчик автотестов Test IT.
🔸 Андрей Козлов, руководитель отдела тестирования и поддержки GitFlic.
🔜Регистрация на бесплатный вебинар
Представь, что ты управляешь огромной библиотекой с миллионами книг.
Посетители заходят, просят книгу и ожидают мгновенного результата. Для этого нужна мощная система поиска.
Именно это делает Elasticsearch для данных.
Думай о Elasticsearch как о Google для твоих данных. Это распределённая, горизонтально масштабируемая поисковая система, которая хранит данные в виде JSON-документов.
Основной поток:
Данные → Индексы → разбиваются на Шарды → распределяются по Нодам → формируют Кластер
Inverted Index → делает поиск очень быстрым
Один разработчик подготовил для нас полноценный и практичный fullstack-шаблон на основе Cloudflare + Next.js: fullstack-next-cloudflare, идеально подходящий для быстрого старта проекта.
Шаблон включает базу данных, хранилище, AI‑вычисления, фронтенд‑фреймворк и другие функции, а также эффективно использует щедрый бесплатный тариф Cloudflare для деплоя.
GitHub: http://github.com/ifindev/fullstack-next-cloudflare
👉 @BackendPortal
7 книг, которые каждый программист должен прочитать хотя бы раз:
① «Cracking the Coding Interview» — Гейл Лакманн МакДауэлл
Полное руководство по техническим собеседованиям с разобранными задачами и понятными стратегиями.
② «Sustainable Code» — Карлос Бле
Как писать программное обеспечение, которое «стареет» хорошо, благодаря тестам и эмерджентному дизайну.
③ «Черная книга программиста» — Рафаэль Гомес Бланес
Рецепты против плохой коммуникации, нереалистичных оценок и постоянно меняющихся требований.
④ «Refactoring» — Мартин Фаулер
Практический метод улучшения дизайна живого проекта, шаг за шагом.
⑤ «The Pragmatic Programmer» — Эндрю Хант и Дэвид Томас
Вневременные принципы для более качественного программирования: от DRY до «программируй, думая о будущих изменениях».
⑥ «Design Patterns» — Эрих Гамма и др.
Словарь проверенных решений для повторяющихся архитектурных задач.
⑦ «Clean Code» — Роберт С. Мартин
Правила и принципы написания читаемого и поддерживаемого кода.
👉 @BackendPortal
Городские сервисы Яндекса отправились в Tech Tour — встречайте в Казани и Нижнем Новгороде
15 и 22 ноября приглашаем на митапы о технологиях в Городских сервисах Яндекса — эксперты выступят с докладами, проведут кейслаб и вайбкодинг для backend-, ML- и DS-разработчиков.
📍В Казани расскажут о том, как в Маркете создали AI-ассистента внутри маркетплейса, разработали поиск лекарств в Еде и научились оптимизировать алгоритмы назначения и распределения исполнителей в Лавке.
📍А в Нижнем Новгороде поделятся, как создают сервис Турбо со скидками для пользователей и поддерживают консистентность данных в продукте.
Кроме докладов и практических активностей в каждом городе будут интерактивы, карьерные смолл-токи и нетворкинг.
📌 Казань, 15 ноября
📌 Нижний Новгород, 22 ноября
Сохраняйте даты и регистрируйтесь!
Мероприятие бесплатное. Количество мест ограничено — пожалуйста, дождитесь нашего подтверждения.
Реклама. ООО «Яндекс.Такси». ИНН: 7704340310. Erid: 2W5zFHt1KQL
🔥Свежий слив курсов!
Python - (170 уроков)
Flask - (122 уроков)
Git - (74 уроков)
OpenCV - (144 уроков)
Flask - (59 уроков)
GameDev - (137 уроков)
Pyramid - (96 уроков)
AIOgram - (34 уроков)
Ruff - (82 уроков)
HTTPX - (57 уроков)
Pyramid - (72 урока)
Django - (132 урока)
NumPy - (46 урока)
Pillow - (74 урока)
PyTorch - (32 урока)
Pymorphy2 - (42 урока)
Получить доступ - /channel/+tQSu_wTnoQ03ZTM6
Ссылка для входа доступна только 48 ч., во избежание блокировок со стороны правообладателя.
На GitHub появился визуальный редактор деплоев, который превращает YAML в удобный drag-and-drop
Объекты можно тянуть мышкой, схемы всегда актуальны, зависимости и апдейты видны в реальном времени, а готовые YAML можно экспортировать или использовать напрямую для GitOps. Шаблоны и переиспользуемые спеки ускоряют работу с кластерами.
https://github.com/kubenote/KubeForge
👉 @BackendPortal
Более 80% компаний из Fortune 500 используют Kafka. Разработчик подготовили видео по её развертыванию на Kubernetes.
В видео показано тестирование устойчивости: сначала отключили один брокер, затем ещё два, чтобы увидеть, как система держит нагрузку.
Смотреть можно здесь — http://youtu.be/Fzf11oPDX1M
👉 @BackendPortal
Распределение памяти это непростая задача.
Можно выделять ровно столько, сколько нужно: это компактно и эффективно. Но как только начинаешь освобождать память, остаётся куча мелких разрозненных дыр, которые толком не используются.
Это называется внешняя фрагментация. Памяти в целом хватает, но она разбросана по разным кускам и не идёт подряд.
Чтобы этого избежать, применяют другой подход — выделение блоков или страниц фиксированного размера. Нужно 8 байт? Всё равно получаешь сразу, например, 4 килобайта. Такая модель и используется сегодня = она решает проблему внешней фрагментации. Тебе дают целый блок, следующие выделения памяти идут из него, пока он не заполнится. Потом выдаётся новый блок.
Модель предсказуемая и именно благодаря ей появилась виртуальная память, разделяемая память и подкачка. Но и у неё есть минусы = при освобождении может оказаться, что у процесса занято десять блоков, а реально используется в каждом всего по байту.
Это уже внутренняя фрагментация. Свободное место внутри блоков есть, но система управления памятью не знает, насколько оно задействовано.
Некоторые сборщики мусора достаточно умны, чтобы находить и уплотнять внутреннюю фрагментацию (если память выделяется через конкретный язык программирования). Например, в Ruby это есть. Но уплотнение тоже требует ресурсов.
Халявы нет = в любом случае чем-то жертвуешь. В этом и состоит дилемма.
👉 @BackendPortal
Reddit имеет более 504 млн пользователей и 91 млн активных в день.
Это безумный масштаб.
Но при миллиардах постов с изображениями GIF и видео Reddit столкнулся с серьёзной проблемой.
Эффективно хранить и отдавать метаданные медиа в масштабе.
С данными у Reddit не было проблем.
Проблема была в другом.
Метаданные медиа включая миниатюры, битрейты, URL для воспроизведения, разрешения и другие параметры были разбросаны по множеству баз данных.
Запросы работали медленно и непоследовательно.
Нужны были единое хранилище и сверхбыстрый доступ.
Новое хранилище метаданных Reddit должно было справляться с более чем 100 тысячами чтений в секунду при задержке меньше 50 миллисекунд, поддерживать последовательное создание и обновление данных, защищать от злонамеренных удалений и хранить все медиа в едином виде.
Самым большим узким местом были чтения.
Cassandra отлично масштабируется, но сложна для ad-hoc запросов и отладки и требует сильной денормализации.
Postgres реляционная, надёжная, легко отлаживается и позволяет делать гибкие запросы.
Reddit выбрал AWS Aurora Postgres.
Архитектура упрощённо включала Aurora Postgres для хранения, PgBouncer для connection pooling, API сервисный слой который экспонирует metadata API, клиентов включая приложения, фиды и рекомендательные системы.
Стандартная трёхуровневая архитектура была оптимизирована для высокой пропускной способности.
Стратегия миграции при нагрузке более 100 тысяч чтений в секунду включала Dual writes которые писали одновременно в новую и старую базу данных, Backfill который копировал исторические метаданные, Dual reads для проверки согласованности данных и постепенный перевод трафика.
Всё это происходило при непрерывной работе Reddit по всему миру.
Запись могла пройти в одной базе и провалиться в другой.
Решение включало Kafka CDC pipeline которая валидировала каждую запись, проверяла согласованность перед коммитом и логировала конфликты для ручного разрешения.
Старые данные из backfill могли перезаписать свежие записи.
Решение включало проверку конфликтов версий с помощью Kafka, логирование несоответствий отдельно и ручную проверку чтобы избежать потерь данных.
Производительность после миграции показала P50 latency меньше 2.6 миллисекунд, P90 latency меньше 4.7 миллисекунд и P99 latency меньше 17 миллисекунд.
Все это достигнуто без кэширования. 😮
👉 @BackendPortal
20 важных объектов/компонентов Kubernetes, которые обязательно нужно знать
20. StatefulSet – Для приложений, которым нужны стабильный сетевой идентификатор и персистентное хранилище, например базы данных.
19. DaemonSet – Гарантирует запуск Pod на каждом (или выбранном) узле, часто используется для агентов логирования и мониторинга.
18. Job – Запускает Pod до успешного завершения задачи, идеально для batch-ворклоадов.
17. CronJob – Планирует Jobs с фиксированными интервалами, например бэкапы или отчётные задачи.
16. NetworkPolicy – Определяет, как Pods общаются между собой и с внешними сервисами, добавляя безопасность.
15. PersistentVolume (PV) – Ресурс хранилища на уровне кластера, предоставляемый админом или динамически через StorageClass.
14. PersistentVolumeClaim (PVC) – Запрос Pod на хранилище, который связывается с PV.
13. StorageClass – Определяет типы хранилища и позволяет динамически создавать тома.
12. HorizontalPodAutoscaler (HPA) – Автоматически масштабирует Pods по CPU, памяти или кастомным метрикам.
11. ResourceQuota – Устанавливает общие лимиты ресурсов (CPU, память, хранилище) на Namespace.
10. LimitRange – Задаёт минимальные и максимальные запросы и лимиты ресурсов для Pods или контейнеров.
9. Role & RoleBinding / ClusterRole & ClusterRoleBinding – Обеспечивают детальный контроль доступа через RBAC.
8. Ingress – Управляет внешним доступом к Services, обычно HTTP/HTTPS, с правилами маршрутизации и TLS.
7. ReplicaSet – Гарантирует, что указанное число реплик Pod всегда запущено.
6. Deployment – Декларативно управляет ReplicaSets для rolling update и масштабирования.
5. Service – Обеспечивает Pods стабильным IP/DNS и умеет балансировать трафик между ними.
4. Pod – Наименьшая единица в Kubernetes, обычно запускает один контейнер (или несколько тесно связанных).
3. ConfigMap – Хранит неконфиденциальные данные конфигурации в виде ключ-значение.
2. Secret – Хранит чувствительные данные (пароли, токены, сертификаты) в закодированном виде.
1. Namespace – Обеспечивает логическую изоляцию и организацию внутри кластера.
Как бэкенд-разработчик, рано или поздно ты поймёшь… дело не только в API и базах данных.
Всё сводится к тому, как системы общаются друг с другом на масштабе. Сможет ли твой сервис выдержать миллионы запросов без падений, выживет ли модель данных, когда продукт внезапно потребует десять новых фич, и сможет ли архитектура развиваться без проблем.
Настоящее веселье начинается, когда выходишь за рамки обычного CRUD
👉 @BackendPortal
Ripgrep - медленный
Nowgrep - быстрый потому что обходит Windows overhead и работает напрямую с NTFS
Вот сравнение Ripgrep и Nowgrep при поиске по 300k файлов на диске с 2M+.
Nowgrep написан с нуля на C99.
Никакого borrow checker.
👉 @BackendPortal
IT_ONE Cup. Code & Analyst — хакатон для аналитиков и разработчиков, где ты узнаешь, как работает IT-команда, и получишь сильный кейс в портфолио. Выбери трек и реши одну из задач:
→ Проанализируй BPMN-модель кредитного процесса и подготовь ТЗ на систему мониторинга эффективности.
→ Разработай сервис, который в реальном времени следит за переводами и оповещает о подозрительных операциях.
🏆 Призовой фонд: 900 000 рублей
💻 Формат: онлайн
🗓 Регистрация до 16 октября: https://cnrlink.com/itonecupmsubeportal
Приглашаем системных аналитиков, разработчиков и менеджеров проектов. Размер команды — от 1 до 5 человек.
Что тебя ждёт:
• Применишь навыки системного анализа, построения архитектуры и работы с потоковыми данными.
• Получишь готовый проект в портфолио.
• Для участников ТОП-5 команд в каждом треке — фирменный мерч.
Задачи соревнования:
Трек 1. Навигатор оптимизации. Проанализируй кредитный процесс банка, выяви узкие места и создай ТЗ для системы мониторинга производительности. Решение поможет оптимизировать критически важные процессы.
Трек 2. Финансовый радар. Разработай сервис для анализа транзакций в реальном времени. Архитектура должна включать правила обнаружения мошенничества и поддержку различных алгоритмов обработки.
Ждём тебя на IT_ONE Cup. Code & Analyst — старт 17 октября на Codenrock: https://cnrlink.com/itonecupmsubeportal
Сохраняйте этот проверенный шаблон бэкенда на .NET — собранный по лучшим отраслевым практикам, чтобы ты мог сосредоточиться на разработке действительно важных функций.
ASP.NET Core Web API, EF Core, PostgreSQL, аутентификация и авторизация, OpenTelemetry, FluentValidation, Swagger, Docker и многое другое
@BackendPortal
Как он развернул facebook без vercel?
👉 @BackendPortal
Индексы — одна из самых критичных концепций для баз данных.
Но чтобы использовать их эффективно, нужно понимать, как они устроены под капотом.
Вот базовые концепции, которые должен знать каждый backend-инженер: ↓
Индексы в базах данных выполняют ту же функцию, что и предметные указатели в книгах.
Они помогают быстро находить данные.
На этом сходство заканчивается, потому что индексы в БД гораздо сложнее.
В целом, выборка данных работает медленно по двум причинам:
Во-первых, нужные данные не всегда помещаются в память.
Во-вторых, данные в базе распределены по диску в случайном порядке.
Поэтому чтение всех данных с диска заняло бы слишком много времени.
Индексы — это структуры данных, которые сокращают время поиска нужных данных.
Но рост производительности при чтении сопровождается компромиссом:
требуется дополнительное место для хранения, а операции записи становятся медленнее.
Индексы предоставляют упорядоченное представление данных независимо от того, где они хранятся.
Базовые строительные блоки индексов — это так называемые "листовые узлы индекса."
Если индекс строится по какому-то столбцу, эти узлы содержат ссылки на физическое расположение строк на диске.
База данных хранит листовые узлы в своей минимальной единице хранения — блоке.
Все блоки имеют одинаковый размер и содержат столько листовых узлов, сколько помещается.
Порядок между листовыми узлами задаётся через двусвязный список.
У двусвязного списка есть два преимущества:
* узлы можно читать как в прямом, так и в обратном направлении;
* при добавлении или удалении строк меняются только указатели.
Проблема в том, что блоки с листовыми узлами тоже лежат на диске в случайных местах.
Поэтому нужна вторая структура данных, которая позволяет быстро находить нужные листовые узлы.
Эту задачу решают B-деревья — древовидные структуры, которые строятся снизу вверх.
Каждый промежуточный узел указывает на наибольшее значение своего подчинённого листового узла.
Такая структура даёт чёткий путь к листовому узлу индекса, который указывает на нужные данные.
Так как B-деревья являются сбалансированными, они поддерживают экспоненциальный рост данных.
По мере экспоненциального увеличения количества листовых узлов высота дерева растёт логарифмически.
👉 @BackendPortal
PocketBase — лёгкий open-source бэкенд в одном файле для быстрого создания приложений с базой данных, аутентификацией, хранением файлов и панелью администратора. Идеален для прототипов и небольших проектов.
👉 @BackendPortal
Прокачай базовые навыки работы с Kubernetes
Вот практическое задание, которое проведёт тебя через весь жизненный цикл Pod’а — от его создания до инспектирования, выполнения команд внутри, просмотра логов и удаления.
Это отличный способ потренироваться, если ты только начинаешь работать с Kubernetes или хочешь увереннее чувствовать себя при работе с kubectl.
Попробуй здесь
👉 @BackendPortal
Неважно, новичок вы или опытный разработчик.
Процессы и синхронизация потоков - сложные темы в программировании.
Дело в том, что в большинстве случаев компьютеры не выполняют инструкции последовательно.
Во-первых, в системе может быть несколько процессоров, работающих одновременно, и тогда сложно определить, выполняется ли инструкция на одном процессоре раньше инструкции на другом.
Во-вторых, один процессор может выполнять несколько потоков. Так как планировщик ОС решает, когда каждый поток выполняется, трудно сказать, в каком порядке это происходит.
В системе с несколькими потоками могут быть участки кода, которые обращаются к общим ресурсам, таким как переменные или файлы.
Обычно требуется синхронизировать доступ потоков к этим ресурсам. Существуют различные инструменты, которые помогают это сделать.
Методы на уровне железа, такие как test-and-set или compare-and-swap, мощные, но сложные.
Именно поэтому большинство языков программирования предоставляет программные инструменты, которые проще использовать.
Мьютексы (mutexes) лучший способ гарантировать, что только один поток может получить доступ к критической секции кода.
Семафоры (semaphores) более универсальны и могут использоваться для сигнализации и синхронизации между потоками.
👉 @BackendPortal
Хотите прокачать навыки full-stack? В курсе от freeCodeCamp вы создадите React-фронтенд на базе Go-бэкенда. На практике вы научитесь настраивать проект, строить API, обрабатывать серверную логику и многое другое. Смотреть курс
👉 @BackendPortal
Нельзя понять производительность SQL-запроса просто по его коду. Для этого нужен план выполнения.
Пример:
select id from student where grade >= 99
Заметки по алгоритмам деревьев Меркла
Дополнительные заметки = https://github.com/t4sk/notes/blob/main/excalidraw/algo/merkle-algo.png
Код на Rust = https://github.com/t4sk/hello-rust/blob/main/merkle/src/main.rs
👉 @BackendPortal
Российский хакер Валерий Илларионов третий раз нашёл лазейку в коде ChatGPT 5
Айтишник за пару дней нашёл способ снять ограничения с GPT и настраивать её под любые задачи — от взлома аккаунтов до изготовления оружия
В своём блоге «Доктор GPT» он делится множеством других лазеек, которые всё ещё не пофиксили.
• Как бесплатно пользоваться Veo 3 и другими генераторами видео
• Как генерировать фото 18+ в Midjourney
• Отключение ограничений в Gemini, GPT и Perplexity
Секретные промты и протоколы собраны здесь — @DoctorGPT 🤫
Готовишься к бэкенд-собеседованиям?
Вот 5 концептов, о которых спрашивают почти всегда:
🔴Connection Pooling
Держим пул готовых подключений к БД вместо открытия нового на каждый запрос. Экономит время и снижает нагрузку на базу.
🔴Thread Pools & Async Processing
Пулы потоков переиспользуют фиксированное число потоков для выполнения задач. Асинхронная обработка позволяет не блокировать выполнение и обслуживать больше запросов одновременно.
🔴Backpressure & Rate Limiting
Backpressure замедляет продюсеров, если консюмеры не успевают. Rate limiting ограничивает количество запросов, которое сервис принимает за единицу времени.
🔴Load Shedding
При перегрузке система отбрасывает часть запросов, чтобы оставаться работоспособной и обрабатывать важные.
🔴Circuit Breakers
Не даём системе бесконечно стучаться в падающий сервис: отключаем запросы на время, потом пробуем снова.
👉 @BackendPortal
Новая фишка для разработчиков данных
DataTUI — терминальный UI для работы с CSV, Excel, SQLite, Parquet и JSON. Сортировка, фильтры, SQL-запросы и мгновенный просмотр схемы прямо в терминале.
Написан на Rust, установка за пару минут.
GitHub: https://github.com/forensicmatt/datatui
👉 @BackendPortal
Как Discord тянет миллион онлайна на одном сервере
По мере роста аудитории Discord отдельные сервера начали упираться в лимиты по пропускной способности и отклику. Нужно было масштабировать их не с десятков тысяч, а сразу до миллионов одновременных пользователей.
Каждое действие в чате вроде отправки сообщения или входа в канал требует обновления UI у всех онлайн. Внутри Discord сервер называется guild и работает в одном Elixir процессе. Отдельный процесс это session для каждого клиента. Guild хранит все сессии участников и управляет их действиями. Обновления из сессий отправляются через вебсокеты клиентам.
Главная проблема это одно сообщение должно улететь всем онлайн. Если на сервере тысяча человек и каждый напишет по сообщению получится миллион доставок.
Как они это решили
1. Passive sessions
Discord стал различать активные и пассивные соединения. Для пассивных клиентов обновления режутся до минимума. Это снизило нагрузку на fanout почти на 90 процентов в больших серверах.
2. Relays
Ввели систему relay что-то вроде многопоточности на уровне инфраструктуры. Fanout теперь распределяется по нескольким машинам. Guild держит только базовую логику а relay процессы подключаются к сессиям, проверяют права и рассылают данные.
3. Worker процессы и ETS
Чтобы не блокировать guild процесс тяжелые операции вынесли в отдельные воркеры. Для работы с огромными списками участников они используют ETS (Erlang Term Storage) быструю in-memory базу к которой безопасно обращаются сразу несколько процессов. Guild создаёт воркер, передаёт ему таблицу ETS и тот делает всю дорогую работу.
В результате логика распределена, нагрузка размазана по воркерам и релеям, данные отправляются только активным пользователям. Всё это вместе позволяет держать миллион и больше онлайна на одном сервере.
👉 @BackendPortal
