Architecture Principle · 09 of 9
Horizontally Scalable
The platform was designed to scale horizontally from day one. Services are stateless. State lives in databases. Capacity grows by adding nodes — not by rewriting code or migrating data.
What this means
In practice.
Same architecture supports 50-user mill and 5000-user mill group
Add capacity by adding nodes — no need to re-architect or re-platform
Background jobs distributed across worker pool — heavy jobs don't slow UI
Connection pooling and caching reduce database load proportionally
How it works
Under the hood.
Stateless app tier
App servers hold no state between requests. Any request can be served by any server.
Queue-driven jobs
Heavy work (reports, exports, bulk imports) queued in BullMQ. Worker pool processes async.
Database replicas
Read queries can route to replicas. Write throughput scaled via connection pooling + partitioning.
CDN + edge cache
Static assets served from CDN. Heavy reads cached at edge for global distribution.
Visual
Same architecture, same code, same data model. Just more nodes.
Real-World Example
Real-world: From 1 plant to 5 plants in 8 months
Before
Customer started with 1 plant, 200 users. Grew to 5 plants, 1200 users in 8 months.
After
No architectural change. Added 2 more app server nodes, 1 more worker pool, scaled Postgres to bigger instance. All transparent to users. No downtime, no migration.
Ready to modernize your mill?
See Papyrus BPApp
in your mill.
Book a personalized demo. We'll walk through every module relevant to your operation — from Deckle optimization to GSTR-3B compliance.