Платформа A-POST-OL
Любой проект начинается не с бизнес-логики, а с фундамента: вход и права доступа, хранение файлов, бизнес-процессы, уведомления, журналирование, отчёты, интеграции. На стандартном стеке это первые месяцы работы и заметная часть бюджета - потраченные не на то, ради чего проект задуман, а на инженерную «обвязку», без которой не обойтись. Именно здесь чаще всего копятся задержки, ошибки и дыры в безопасности.
Платформа - это и есть тот самый фундамент, только уже построенный: отлаженный годами и проверенный не на одном, а на десятке систем в реальной эксплуатации. Вы стартуете не с нуля, а с надёжного основания - время и бюджет идут на бизнес-логику вашего проекта, ту часть, что отличает его от других и приносит деньги, а не на повторное возведение того, что уже многократно построено и испытано.
← Услуги и ценыСостав платформы
Из чего состоит фундамент: базовые блоки, готовые подсистемы и инженерное ядро. Всё - с открытым исходным кодом.
Что вы получаете из коробки
Вход и права доступа
Регистрация, вход (в том числе через OAuth2 и соцсети), роли и тонкая настройка «кто что видит и может».
Документы и справочники
Единая модель для клиентов, счетов, заказов, договоров - с историей изменений и жизненным циклом.
Бизнес-процессы
Статусы и переходы (заявка → в работе → закрыто) настраиваются как данные. Процесс меняется без пересборки системы.
Файлы и хранилище
Вложения, сканы, фотографии. Облачное S3-совместимое хранение из коробки.
Уведомления и реальное время
Мгновенные обновления в интерфейсе, email/SMS/push, подтверждение почты и телефона.
Журнал и аудит
Кто, что и когда сделал - полный след для разбора спорных ситуаций и регуляторных требований.
Отчёты и выгрузки
Построение отчётов и документов по данным системы.
Интеграции
Готовый REST API на сотни методов, приём вебхуков и вызовы внешних сервисов - платёжных систем, AI, госсервисов - прямо из системы.
Десятки модулей · сотни готовых методов REST API · мультиязычность · адреса РФ (КЛАДР) · настройки в рантайме без программиста
Готовые подсистемы
Сверх базовых блоков - целые бизнес-механизмы, уже собранные и обкатанные на нескольких проектах. Их не нужно проектировать заново.
Платежи и эквайринг
Приём платежей через Stripe и ЮKassa под разные рынки - единым способом. Привязка карт и автосписание, резервирование суммы (pre-auth hold), возвраты, проверка карты, оплата счетов.
Учёт по счетам (двойная запись)
Лицевые счета: кошельки, обязательства, задолженности. Обороты по дебету и кредиту, входящий и исходящий остаток, оборотная ведомость с агрегацией по дням, неделям и месяцам. Бухгалтерская строгость на уровне базы.
Подписки и биллинг
Продукты, тарифы и периоды; автопродление по расписанию, пробный период, смена тарифа с pro-rata пересчётом остатка, отмена. Полный жизненный цикл подписки и привязка к лимитам (например, числу устройств).
Одни и те же блоки лежат в основе систем для зарядок EV, AI-генерации, геодезии и взыскания ЖКХ-задолженности.
Под капотом
Три инженерных решения, на которых держатся и скорость, и надёжность. Здесь - суть; подробный разбор для технических специалистов - ниже, в разделе «Одно ключевое отличие».
Ноль слоёв между запросом и базой
Большинство фреймворков добавляют между HTTP-запросом и PostgreSQL несколько слоёв - ORM, отдельный пул соединений, свой IO-цикл. A-POST-OL убирает всё лишнее: HTTP и PostgreSQL работают в одном epoll-цикле. Результат - не только скорость, но и архитектурная простота: меньше движущихся частей, меньше мест для ошибки, меньше дополнительных сервисов.
Консистентность данных
Бизнес-логика живёт в самой PostgreSQL: транзакции, проверка остатков, расчёт цен, защита от двойных списаний - атомарны на уровне БД, без промежуточных слоёв. Это критично для e-commerce и финансовых операций. Близкий подход у Supabase, но там прикладную логику принято ограничивать RLS и edge-функциями - здесь же на PL/pgSQL реализована вся бизнес-логика.
Единый event loop, асинхронный PostgreSQL без потоков и блокирующих вызовов - следствие той же архитектуры: на чистом HTTP - 90% скорости nginx, а в производственном сценарии, с запросом к базе на каждый HTTP-запрос, - 112 тысяч RPS при задержке меньше миллисекунды. Открытый бенчмарк:
A-POST-OL (libapostol)
Фреймворк на C++20. HTTP/WebSocket-сервер, асинхронный PostgreSQL, единый цикл событий на epoll. Автоматическая генерация OpenAPI и Swagger UI.
github.com ↗PostgreSQL Framework for Backend Development
Десятки модулей PL/pgSQL: REST API, OAuth 2.0, движок бизнес-процессов, файловое хранилище, подписки на события, система отчётов. Превращает PostgreSQL в полноценный сервер приложений.
github.com ↗Состав понятен. Первый вопрос, который задаёт любой технический заказчик: насколько это надёжно?
Завод, а не гараж
Вы получаете не одинокий станок в гараже, а полноценный завод с множеством независимых производственных линий: они не валятся разом, чинятся на ходу и обновляются без остановки. Зрелость, проверенная годами эксплуатации.
Приложение на A-POST-OL - один исполняемый файл, внутри которого главный процесс управляет независимыми «службами»: HTTP-обработчик, WebSocket-сервер, планировщик задач, генератор отчётов, OCPP-процессор. Упала одна - остальные работают, система сама поднимает замену. При этом своим компонентам не нужны ни HTTP-вызовы друг к другу, ни брокеры: модули с общими данными живут в одном процессе с общим epoll-циклом, а границу между процессами данные пересекают через PostgreSQL. По сути - микросервисная изоляция без микросервисной инфраструктуры.
Микросервисы - это парк отдельных грузовиков: один сломался, другие везут, но вы содержите целую логистическую компанию, чтобы их координировать. A-POST-OL - это один хорошо построенный завод с независимыми линиями: линия заклинила - остальные работают, а мастер тут же её перезапускает. А чтобы пережить пожар всего завода, строят второй завод - ровно как и все.
Надёжность - не в том, чтобы ничего не ломалось, а в том, чтобы поломка не валила всё.
Надёжность уровня nginx и PostgreSQL
Внутри система устроена так же, как самые проверенные программы в мире - веб-серверы и базы данных, которым доверяют банки: главный процесс управляет множеством рабочих. Упал один - остальные продолжают обслуживать, а система сама поднимает замену. Фоновые службы (рассылки, расписания, отчёты) работают отдельно: отвалился генератор отчётов - приём запросов не пострадал. Это та самая изоляция, которой хвалятся микросервисы, - но уже внутри одного приложения.
Обновления выкатываются плавно, без простоя - пользователи не замечают. А чтобы пережить отказ целого сервера или гигантскую нагрузку, добавляется обычный, скучный набор: второй сервер за балансировщиком и копия базы. Это стандартно и подключается тогда, когда реально понадобится, - архитектура этому не мешает.
Что это даёт вам
Сбой не роняет всё
Отдельная служба может упасть и сама перезапуститься - система продолжает работать.
Обновления без простоя
Новые версии поднимаются плавно; пользователи не видят остановки.
Растёт вместе с вами
Под отказ сервера и большую нагрузку добавляется стандартный набор - не раньше, чем понадобится.
Микросервисы дают такую устойчивость «из коробки», но ценой постоянной операционной сложности. Здесь надёжность есть сразу, а масштаб добавляется по мере необходимости - для большинства бизнес-систем это более трезвый выбор.
Платформа - конструктор из трёх слоёв
Один и тот же стек у множества production-проектов. Меняется только верхний слой - бизнес-логика.
Configuration - ваш проект
Уникальная бизнес-логика. Всё, что отличает CSMS от ERP, живёт в этом слое.
auth · OAuth 2.0 · workflow · entity · файлы (S3) · pub/sub · audit log · notifications · локализация · отчёты · registry · KLADR · …
Десятки модулей · сотни REST-методов · никто не пишет ни строки в этом слое
HTTP / WebSocket · TLS · epoll · libapostol
Как nginx или сама PostgreSQL - не часть вашего проекта.
Десятки модулей платформы переиспользуются во множестве проектов без единой строки своего кода. Модуль приёма платежей Stripe, написанный для CopyFrog, без переделки переиспользуется в других проектах - например, в Apostol CSMS. По тому же принципу собирается интернет-магазин, ERP или IoT-платформа - уникальная логика живёт только в верхнем слое.
Workflow engine - это данные
Состояния, переходы и события бизнес-процессов хранятся в таблицах БД, а не в коде. Меняете workflow без пересборки сервиса.
- на практике это решение снова и снова оказывается самым полезным в архитектуре платформы.
Время - это деньги
Платформа - это не только технология, но и многие месяцы работы команды разработчиков, которые в обычном проекте уходят на инфраструктуру: auth, workflow, REST, файлы, очереди, audit log, локализацию. Здесь это уже отлажено в production у множества систем. Бюджет вашего проекта остаётся на бизнес-логику, а не на повторное изобретение колеса.
- по моей оценке, повторить сопоставимую по зрелости систему с нуля без новых возможностей на стандартном стеке заняло бы годы разработки и миллионы бюджетных средств.
Одно ключевое отличие
Конструктор из трёх слоёв - это ЧТО. Здесь - ПОЧЕМУ именно так, а не стандартным стеком. Раздел для технического читателя: если техника не про вас, достаточно врезки ниже - остальное можно смело пролистать.
В обычной архитектуре приложение и база данных - два отдельных мира: данные ходят между ними туда-обратно, и каждый переход стоит времени и создаёт место для ошибки - вплоть до двойного списания денег. В A-POST-OL приложение и база работают как одно целое: любая операция с деньгами - одно неделимое действие. Отсюда скорость без дорогого «железа» и невозможность целого класса дорогих ошибок - по построению, а не благодаря аккуратности программиста.
Возьмём конкретную задачу: «Проверить баланс и списать деньги» Она есть в каждом транзакционном проекте - e-commerce, биллинг, ERP, ЖКХ.
На Python / Node.js / Go:
Проблема: временной зазор
Между SELECT и UPDATE - временной зазор. Параллельный запрос успевает прочитать тот же баланс до того как первый его обновил. Итог: двойное списание, oversell, гонка при бронировании. Решение - явная дополнительная механика: SELECT FOR UPDATE, optimistic locking, Redis-блокировка. Это хорошо известные инструменты - но это дополнительный код, дополнительные зависимости и дополнительное место для ошибки.
На A-POST-OL:
Нет зазора. Нет трёх round trip'ов. Нет дополнительных блокировок. PostgreSQL сериализует параллельные вызовы самостоятельно - это свойство ACID, а не дополнительный код.
Когда нужна передача данных между процессами
например, поток событий из внешнего источника (IoT, биржа, телеметрия)
На Python:
Типичный сервис обработки событий на Python делает 5–7 сериализаций на каждое событие. При 1 000 событий/сек - это тысячи операций только на то, чтобы передать число из одного своего процесса в другой. CPU уходит на транспорт, не на бизнес-логику.
На A-POST-OL:
Компоненты, которые в Python были бы отдельными процессами, здесь - модули одного процесса с общим epoll-циклом: кэш читается напрямую из памяти самого процесса. Границу между процессами данные пересекают один раз - через PostgreSQL LISTEN/NOTIFY. Нет Redis. Нет JSON между своими модулями. Ноль сериализаций внутри процесса - и ровно одна на границе, вместо пяти-семи.
Почему это возможно: база данных - не «внешний сервис», а часть приложения
Python / Node.js / Go
В Python/Node.js/Go - PostgreSQL это внешний сервис. Каждый вызов: взять соединение из пула → отправить по TCP → ждать → получить → распарсить. Даже с async-драйвером остаются пул соединений, разбор протокола на стороне приложения и накладные расходы рантайма.
A-POST-OL
В A-POST-OL - сокет PostgreSQL зарегистрирован в том же epoll-цикле, что и HTTP-сокеты. Когда база ответила - epoll срабатывает так же, как когда клиент прислал следующий байт. Нет отдельного потока в ожидании. Нет контекстного переключения. Нет очереди между «получил HTTP-запрос» и «ответил из базы». База - «на расстоянии вытянутой руки».
| Python / Node.js / Go | A-POST-OL | |
|---|---|---|
| Обращение к PostgreSQL | TCP + парсинг + пул потоков | epoll event в том же цикле |
| Передача данных между процессами | Redis / Kafka / gRPC | libpq NOTIFY / память |
| Гонка при check + update | нужны явные блокировки | устранена архитектурно |
| Redis как кэш | нужен - PG «далеко» | не нужен - PG и так «рядом» |
| Брокер сообщений | нужен для async workflow | PostgreSQL LISTEN/NOTIFY |
Именно отсюда 507K RPS на чистом HTTP - и 112K RPS, когда каждый запрос ходит в базу. Именно поэтому брокер сообщений не нужен для внутренней коммуникации. Именно поэтому бизнес-логика может жить внутри транзакции без накладных расходов - потому что вызов к базе стоит столько же, сколько обработка следующего HTTP-пакета.
В переводе с инженерного: там, где обычно собирают кластер сервисов, здесь хватает одного недорогого сервера; в схеме меньше компонентов, которые могут отказать и которые нужно оплачивать и обслуживать; а ошибки класса «деньги списались дважды» исключены самой конструкцией.
A-POST-OL создавался как ответ на конкретный вопрос: как убрать все слои между HTTP-запросом и транзакцией PostgreSQL. OCPP (протокол зарядных станций) - наглядный пример, где это требование стоит остро: тысячи станций, постоянные WebSocket-соединения, каждое сообщение должно попасть в базу атомарно и немедленно. Та же архитектура работает в ERP, финтехе и IoT - потому что требование одно и то же: данные консистентны, а не «eventually consistent». Цена архитектурного решения - бизнес-логика на PL/pgSQL вместо привычных Python или Go. Разработчиков, которые пишут прикладную логику на PL/pgSQL, на рынке труда немного. Это реальное ограничение, о котором лучше знать заранее.
Платформа - это ядро, к которому подключаются микросервисы на уместном языке. В DEBT-Master вокруг ядра работают пять Python-сервисов (парсинг Excel/PDF/RTF, OCR, генерация документов); в CopyFrog - оркестрация AI-провайдеров. Правильный инструмент под задачу, а не «всё одним стеком любой ценой».
Почему свой путь, а не проторённая дорога
Три вопроса, которые обычно остаются у опытного скептика после всего прочитанного, - и ответы по существу.
Если эта архитектура настолько выигрышна - почему так не строят все?
Потому что массовый стек решает другую задачу. Он оптимизирован под главное ограничение больших организаций: десятки взаимозаменяемых разработчиков, которых нужно быстро нанимать и безболезненно заменять. Отсюда его слои: ORM - чтобы не требовать глубокого SQL, микросервисы - чтобы делить работу между командами, брокеры сообщений - чтобы команды не согласовывали каждый релиз. Для той задачи это рациональные решения.
Здесь ограничение другое: компактная команда, транзакционная корректность и дешёвая эксплуатация на годы вперёд. Другое ограничение - другой оптимум. Свой путь - не бунт против индустрии, а честная оптимизация под свою задачу.
Бизнес-логика в базе данных? Это уже проходили в 2000-х - и отказались
Отказались заслуженно - но не от идеи, а от инструментария эпохи: код хранимых процедур жил вне систем контроля версий, без тестов и ревью, привязывал к дорогой проприетарной СУБД, а каждое изменение стояло в очереди к администратору базы.
Здесь всё это устранено конструктивно иначе: PostgreSQL - открытая и бесплатная; исходный код на PL/pgSQL живёт не в БД, а обычными файлами в git - с ревью, автоматическим развертыванием (загрузкой в БД при деплое), контролируемыми миграциями и сотнями автотестов; у каждой сущности - один и тот же дисциплинированный набор файлов; REST-слой строится автоматически. Показательно, что индустрия и сама возвращается к логике рядом с данными: Supabase, PostgREST, Hasura - шаги по той же дороге.
Общая картина видна на реальных проектах: у DEBT-Master, CopyFrog, campus/cors и Apostol CSMS - у каждого свой git-репозиторий и свой Docker Compose, но принцип один: весь PL/pgSQL-код лежит обычными файлами в этом репозитории, версионируется и ревьюится как любой другой код, а Docker Compose лишь разворачивает его в контейнере с PostgreSQL при старте или обновлении - то есть база данных для PL/pgSQL-кода то же самое, чем Docker-образ является для кода на Python, Node.js или Go: упаковка и среда исполнения, а не хранилище исходников. Открытый минимальный пример этого - шаблон Apostol CRM:
→ Apostol CRM - git clone → docker-build.sh → docker-up.shВ Apostol CSMS этот же принцип доведён до полноценного конвейера: пять исходных репозиториев (backend, ocpp, db, frontend, auth) публикуются по единому git-тегу; каждый бренд-деплой фиксирует точные версии в одном lock-файле и переезжает на новый релиз одной командой; а накат схемы базы - обязательный блокирующий шаг конвейера: если миграция не прошла, выкладка новой версии останавливается сама, без ручного администратора базы на другом конце.
Платформа одного автора - откуда взяться зрелости?
Оттуда же, откуда она у Rails, выросшего из Basecamp, и у Django, выросшего из газетной редакции: платформа не проектировалась «на бумаге» - она выделена из работающих заказных систем. Каждый модуль появился потому, что понадобился реальному проекту, и обкатан в нескольких непохожих доменах.
Поэтому в ней нет умозрительных возможностей «на вырост» - только то, что уже окупило себя в эксплуатации с 2017 года. А открытый код позволяет проверить это чтением, а не доверием.
Архитектура платформы универсальна
Платформа подходит для любого проекта, где нужна надёжная серверная часть с готовой инфраструктурой. Apostol CSMS - лишь один из примеров. Ваш проект может стать следующим.
E-commerce
Multi-tenant, multi-payment, расчёт налогов по странам, очереди для интеграций с маркетплейсами (Amazon, Wildberries), журнал действий, защита от двойных списаний.
FinTech
Real-time данные через WebSocket, OAuth 2.0, биллинг и сверка платежей, журнал действий, интеграции с биржами и платёжными системами.
ERP / документооборот
Workflow-движок (состояния, переходы, события), документооборот, отчёты, файловое хранилище с S3-совместимостью, мультиязычность.
IoT и зарядная инфраструктура
Высокая нагрузка через единый event loop, persistent WebSocket-соединения, OCPP/OCPI/NTRIP, обработка телеметрии в реальном времени.
AI-сервисы
Асинхронные задачи, очереди для LLM API, file storage для входных данных и результатов, биллинг по использованию, multi-tenant.
SaaS общего назначения
Authentication из коробки (OAuth 2.0, JWT, signup), tenant-изоляция, white-label, локализация, журнал действий - всё, что нужно стартующему SaaS.
Идеально подходит
- ✓Транзакционные системы: финтех, биллинг, e-commerce, ERP, платежи, ЖКХ-автоматизация
- ✓Real-time и долгоживущие соединения: IoT, зарядки (OCPP), телеметрия, стриминг, WebSocket
- ✓Multi-tenant SaaS / white-label, режим 24/7, дешёвая эксплуатация
- ✓Интеграционные хабы - оркестрация прямо из базы данных
Лучше искать иное решение
- →Frontend/UX-first продукты с тонким бэкендом - платформа избыточна
- →Продукты, где ядро ценности - ML/AI-пайплайны (платформа подойдёт только вокруг них)
- →Когда нужно быстро нанять большую команду и важна ликвидность «модного» стека
- →Глобальный горизонтальный масштаб с первого дня
Apostol CSMS (зарядная инфраструктура) - пример зрелого SaaS-продукта на платформе. Архитектура та же, домен другой.
Подробнее об архитектуре платформы →Обсудить ваш проект
Расскажите о задаче - отвечу в течение дня. Бесплатный созвон 30 минут и письменный ориентир по срокам и бюджету.
Связаться