The A-POST-OL platform
Every project starts not with business logic but with a foundation: login and access control, file storage, business processes, notifications, logging, reports, integrations. On a conventional stack that's the first months of work and a sizeable slice of the budget - spent not on what the project is for, but on engineering plumbing you can't do without. And that's exactly where delays, bugs and security holes tend to accumulate.
The platform is that foundation - already built, refined over years and proven not on one but on a dozen systems in real production. You start not from zero but from a solid base: time and budget go to your project's business logic - the part that sets it apart and earns money - instead of re-laying what has already been built and battle-tested many times over.
← Services & pricingInside the platform
What the foundation is made of: core building blocks, ready-made subsystems and the engineering core. All open source.
What you get out of the box
Login & access control
Sign-up, sign-in (including OAuth2 and social), roles and fine-grained "who can see and do what".
Documents & catalogues
One model for clients, accounts, orders, contracts - with change history and lifecycle.
Business processes
Statuses and transitions (request → in progress → closed) configured as data. The process changes without rebuilding the system.
Files & storage
Attachments, scans, photos. S3-compatible cloud storage out of the box.
Notifications & real time
Instant UI updates, email/SMS/push, email and phone verification.
Audit log
Who did what and when - a full trail for disputes and regulatory requirements.
Reports & exports
Building reports and documents from the system's data.
Integrations
A ready REST API with hundreds of methods, inbound webhooks and calls to external services - payment systems, AI, government services - straight from the system.
Dozens of modules · hundreds of ready REST API methods · multi-language · Russian address registry (KLADR) · runtime configuration without a developer
Ready-made subsystems
Beyond the basic blocks - whole business mechanisms, already assembled and proven across several projects. No need to design them from scratch.
Payments & acquiring
Accepting payments via Stripe and YooKassa for different markets - through one interface. Card binding and auto-charge, amount reservation (pre-auth hold), refunds, card validation, invoice settlement.
Account ledger (double-entry)
Personal accounts: wallets, liabilities, debts. Debit and credit turnover, opening and closing balances, a turnover report with day/week/month aggregation. Accounting rigour at the database level.
Subscriptions & billing
Products, plans and periods; scheduled auto-renewal, trial period, plan change with pro-rata recalculation, cancellation. The full subscription lifecycle, tied to limits (e.g. number of devices).
The same blocks power systems for EV charging, AI generation, geodesy and utility-debt collection.
Under the hood
Three engineering decisions that both the speed and the reliability rest on. Here is the gist; the detailed breakdown for technical readers is below, in "One Key Difference".
Zero layers between request and database
Most frameworks insert several intermediate layers between an HTTP request and PostgreSQL - an ORM, a separate connection pool, their own IO cycle. A-POST-OL removes the unnecessary parts: HTTP and PostgreSQL run in the same epoll loop. The result is not just speed - it is architectural simplicity: fewer moving parts, fewer places for bugs, fewer extra services.
Data consistency
Business logic lives inside PostgreSQL itself: transactions, stock checks, price calculations, double-charge protection - atomic at the database level, no intermediate layers. Critical for e-commerce and financial operations. A similar approach to Supabase, but application logic there is conventionally kept to RLS and edge functions - here all business logic is in PL/pgSQL.
A single event loop, async PostgreSQL with no threads or blocking calls - a consequence of the same architecture: 90% of nginx speed on pure HTTP, and in the production scenario - a database query on every HTTP request - 112K RPS at sub-millisecond latency. Open benchmark:
A-POST-OL (libapostol)
C++20 framework. HTTP/WebSocket server, async PostgreSQL, single epoll event loop. Automatic OpenAPI spec + Swagger UI generation.
github.com ↗PostgreSQL Framework for Backend Development
Dozens of PL/pgSQL modules: REST API, OAuth 2.0, workflow engine, file storage, pub/sub, report system. Turns PostgreSQL into a full-featured application server.
github.com ↗So that's what's inside. The first question any technical customer asks: how reliable is it?
A factory, not a garage
You get not a lone machine in a garage, but a complete factory with many independent production lines: they don't all go down together, they self-heal on the fly, and they update without stopping. Maturity proven by years in production.
An A-POST-OL application is a single binary in which a master process supervises independent "services": HTTP handler, WebSocket server, task scheduler, report generator, OCPP processor. One fails - the others keep running, and the system brings up a replacement on its own. Its components need no HTTP calls to each other and no brokers: modules that share data live in one process with a shared epoll loop, and data crosses process boundaries through PostgreSQL. In essence - microservice isolation without microservice infrastructure.
Microservices are a fleet of separate trucks: one breaks down, the others keep delivering - but you run a whole logistics company to coordinate them. A-POST-OL is one well-built factory with independent lines: a line jams, the others keep running, and the foreman restarts it at once. And to survive the whole factory burning down, you build a second factory - exactly like everyone else.
Reliability isn't that nothing ever breaks - it's that a breakage doesn't take everything down.
Reliability on par with nginx and PostgreSQL
Inside, the system is built the same way as the most trusted software in the world - the web servers and databases banks rely on: a master process supervises many workers. One falls - the others keep serving, and the system brings up a replacement itself. Background services (mailouts, schedules, reports) run separately: the report generator dies - request handling is unaffected. That's the very isolation microservices boast about - already inside a single application.
Updates roll out smoothly, with no downtime - users don't notice. And to survive a whole-server failure or huge load, you add the ordinary, boring set: a second server behind a load balancer and a copy of the database. It's standard and plugs in when you actually need it - the architecture doesn't get in the way.
What this gives you
A failure doesn't bring it all down
A single service can crash and restart itself - the system keeps running.
Updates with no downtime
New versions come up smoothly; users see no interruption.
Grows with you
For server failover and heavy load you add a standard set - not before you need it.
Microservices give this resilience out of the box, but at the cost of constant operational complexity. Here reliability is there from the start, and scale is added as needed - for most business systems that's the more sober choice.
The platform - a three-layer toolkit
Same stack across many production projects. Only the top layer - business logic - changes.
Configuration - your project
Unique business logic. Everything that makes CSMS different from an ERP lives in this layer.
auth · OAuth 2.0 · workflow · entity · files (S3) · pub/sub · audit log · notifications · localization · reports · registry · KLADR · …
Dozens of modules · hundreds of REST methods · nobody writes a line in this layer
HTTP / WebSocket · TLS · epoll · libapostol
Like nginx or PostgreSQL itself - not part of your project.
Dozens of platform modules are reused across many projects without writing a single line of their own. The Stripe payment module, written for CopyFrog, is reused as-is in other projects - for example, in Apostol CSMS. The same principle assembles an e-commerce site, an ERP, or an IoT platform - unique logic lives only in the top layer.
Workflow engine - as data
States, transitions, and events of your business processes are stored in DB tables, not in code. Change the workflow without redeploying the service.
- in practice, this is the decision that keeps proving itself the most useful in the platform's architecture.
Time is money
The platform is not just technology - it's many months of team work that, in a typical project, gets spent on infrastructure: auth, workflow, REST, files, queues, audit log, localization. Here it already runs in production across many systems. Your project's budget stays on business logic, not on reinventing the wheel.
- in my own estimate, rebuilding a comparably mature system from scratch on a standard stack, with no new features, would take years of development and millions in budget.
One Key Difference
The three-layer constructor is the WHAT. Here is the WHY - why this architecture instead of the standard stack. A section for the technical reader: if tech is not your thing, the callout below is enough - feel free to skip the rest.
In a conventional architecture the application and the database are two separate worlds: data travels back and forth between them, and every crossing costs time and creates room for error - up to charging money twice. In A-POST-OL the application and the database work as one: any money operation is a single indivisible action. Hence the speed without expensive hardware - and the impossibility of a whole class of costly errors, by construction rather than by a programmer's diligence.
Take a concrete task: "Check balance and charge money" It appears in every transactional project - e-commerce, billing, ERP, utility collection.
In Python / Node.js / Go:
The problem: a temporal gap
Between SELECT and UPDATE there is a temporal gap. A concurrent request can read the same balance before the first one has updated it. Result: double charge, oversell, booking race. The fix - explicit extra mechanics: SELECT FOR UPDATE, optimistic locking, Redis lock. These are well-known tools - but they are extra code, extra dependencies, and extra places for bugs.
In A-POST-OL:
No gap. No three round trips. No extra locks. PostgreSQL serializes concurrent calls on its own - that is an ACID property, not extra code.
When inter-process data transfer is needed
e.g. an event stream from an external source (IoT, exchange, telemetry)
In Python:
A typical Python event-processing service performs 5–7 serializations per event. At 1,000 events/sec that is thousands of operations just to pass a number from one own process to another. CPU goes to transport, not business logic.
In A-POST-OL:
Components that would be separate processes in Python are modules of one process here, sharing one epoll loop: the cache is read directly from the process's own memory. Data crosses a process boundary exactly once - via PostgreSQL LISTEN/NOTIFY. No Redis. No JSON between own modules. Zero serializations inside the process - and exactly one at the boundary, instead of five to seven.
Why this is possible: the database is not an "external service" but part of the application
Python / Node.js / Go
In Python/Node.js/Go - PostgreSQL is an external service. Every call: borrow connection from pool → send over TCP → wait → receive → parse. Even with an async driver you still pay for the connection pool, application-side protocol parsing and runtime overhead.
A-POST-OL
In A-POST-OL - the PostgreSQL socket is registered in the same epoll loop as the HTTP sockets. When the database responds - epoll fires the same way as when a client sends the next byte. No separate thread waiting. No context switch. No queue between "received HTTP request" and "answered from database". The database is at arm's length.
| Python / Node.js / Go | A-POST-OL | |
|---|---|---|
| PostgreSQL access | TCP + parse + thread pool | epoll event in the same loop |
| Inter-process transfer | Redis / Kafka / gRPC | libpq NOTIFY / memory |
| Race on check + update | explicit locks required | eliminated architecturally |
| Redis as cache | needed - PG is "far" | not needed - PG is already "close" |
| Message broker | needed for async workflow | PostgreSQL LISTEN/NOTIFY |
That is why 507K RPS on pure HTTP - and 112K RPS when every request touches the database. That is why no message broker is needed for internal communication. That is why business logic can live inside a transaction without overhead - because a database call costs the same as processing the next HTTP packet.
Translated from engineering: where a cluster of services is usually assembled, one modest server is enough; the scheme has fewer components that can fail and that need to be paid for and maintained; and errors of the "money charged twice" class are ruled out by the construction itself.
A-POST-OL was built as an answer to one specific question: how to remove all layers between an HTTP request and a PostgreSQL transaction. OCPP (the EV charging protocol) is a clear example where this matters acutely: thousands of stations, persistent WebSocket connections, every message must land in the database atomically and immediately. The same architecture works in ERP, fintech, and IoT - because the requirement is the same: data is consistent, not "eventually consistent". The price of this architectural choice is business logic in PL/pgSQL instead of the familiar Python or Go. Developers who write application-level code in PL/pgSQL are relatively rare. This is a real constraint worth knowing upfront.
The platform is a core you connect microservices to, in whatever language fits. DEBT-Master runs five Python services around the core (Excel/PDF/RTF parsing, OCR, document generation); CopyFrog orchestrates AI providers. The right tool for the job - not "everything in one stack at any cost".
Why its own path, not the beaten road
Three questions an experienced sceptic is usually left with after reading all of the above - answered on the merits.
If this architecture is such a win - why doesn't everyone build this way?
Because the mainstream stack solves a different problem. It is optimised for the main constraint of large organisations: dozens of interchangeable developers who must be hired fast and replaced painlessly. Hence its layers: an ORM so deep SQL isn't required, microservices so work can be split between teams, message brokers so teams don't have to coordinate every release. For that problem these are rational choices.
The constraint here is different: a compact team, transactional correctness and cheap operation for years ahead. A different constraint - a different optimum. Taking its own path is not a rebellion against the industry; it is honest optimisation for the actual problem.
Business logic in the database? The 2000s tried that - and walked away
They walked away deservedly - not from the idea, but from the tooling of the era: stored-procedure code lived outside version control, without tests or review, locked you into an expensive proprietary DBMS, and every change queued behind a database administrator.
All of that is removed by construction here, but differently: PostgreSQL is open and free; the PL/pgSQL source of truth is not the database but ordinary files in git - with review, automated deployment (loading into the database on deploy), controlled migrations and hundreds of automated tests; every entity follows the same disciplined file layout; the REST layer is generated. Tellingly, the industry itself is drifting back towards logic next to the data: Supabase, PostgREST and Hasura are steps down the same road.
The same pattern shows up across real projects: DEBT-Master, CopyFrog, campus/cors and Apostol CSMS each have their own git repository and their own Docker Compose file, but the principle is identical: all PL/pgSQL code lives as ordinary files in that repository, versioned and reviewed like any other code, while Docker Compose only deploys it into a PostgreSQL container at startup or on update - in other words, the database is to PL/pgSQL code what a Docker image is to Python, Node.js or Go code: packaging and a runtime, not where the source lives. An open, minimal example of this - the Apostol CRM template:
→ Apostol CRM - git clone → docker-build.sh → docker-up.shApostol CSMS takes the same principle into a full pipeline: five source repositories (backend, ocpp, db, frontend, auth) are published from a single git tag; each brand deployment pins exact versions in one lock file and moves to a new release with a single command; and rolling out the database schema is a mandatory blocking step of that pipeline - if a migration fails, the rollout stops itself, with no database administrator waiting on the other end.
A single-author platform - where would maturity come from?
From the same place Rails got it, having grown out of Basecamp, and Django, having grown out of a newspaper: the platform was not designed on paper - it was extracted from working custom systems. Every module exists because a real project needed it, and has been proven across several unrelated domains.
That is why it carries no speculative just-in-case features - only what has already paid for itself in production since 2017. And the open source lets you verify this by reading, not by trust.
The platform architecture is universal
The platform fits any project that needs a reliable backend with built-in infrastructure. Apostol CSMS is just one example. Your project can be next.
E-commerce
Multi-tenant, multi-payment, country-based tax calculation, queues for marketplace integrations (Amazon, eBay), audit trail, oversell protection.
FinTech
Real-time data via WebSocket, OAuth 2.0, billing and reconciliation, audit trail, exchange and payment integrations.
ERP / document workflow
Workflow engine (states, transitions, events), document management, reports, S3-compatible file storage, localization.
IoT and charging infrastructure
High load via single event loop, persistent WebSocket connections, OCPP/OCPI/NTRIP, real-time telemetry processing.
AI services
Async tasks, queues for LLM APIs, file storage for inputs and results, usage-based billing, multi-tenant.
General-purpose SaaS
Authentication out of the box (OAuth 2.0, JWT, signup), tenant isolation, white-label, localization, audit trail - everything a starting SaaS needs.
Ideal fit
- ✓Transactional systems: fintech, billing, e-commerce, ERP, payments, utility automation
- ✓Real-time and long-lived connections: IoT, charging (OCPP), telemetry, streaming, WebSocket
- ✓Multi-tenant SaaS / white-label, 24/7 operation, cheap to run
- ✓Integration hubs - orchestration straight from the database
Better to look elsewhere
- →Frontend/UX-first products with a thin backend - the platform is overkill
- →Products whose core value is ML/AI pipelines (the platform only fits around them)
- →When you need to hire a large team fast and value mainstream-stack liquidity
- →Global horizontal scale from day one
Apostol CSMS (EV charging infrastructure) is one example of a mature SaaS product on the platform. Same architecture, different domain.
Learn more about the platform architecture →Discuss your project
Tell me about your task - I reply within a day. A free 30-minute call and a written estimate of timeline and budget.
Get in touch