Scale Monolithic SaaS Application

Our SaaS B2B application is currently hosted on a DigitalOcean Droplet, while the database layer is managed through DigitalOcean Managed PostgreSQL. The application currently follows a monolithic architecture. While this has worked well so far, there is growing concern around scalability as user adoption increases. The primary bottleneck is expected to be PDF generation, which is computationally expensive and could create queue/worker contention under high concurrency. If many users trigger PDF exports simultaneously, worker exhaustion, queue delays, memory pressure, and degraded application responsiveness could occur. The main goal is to design a scalable and resilient architecture that prevents PDF generation workloads from negatively affecting the overall platform. About product: Core Shape: The domain is: Workspace -> Protocol -> Inbox. A Workspace is the tenant and billing boundary. A Protocol is the reusable template/procedure. A Protocol Component is one builder block inside that protocol. An Inbox is a filled submission created from a protocol. Stack: - Backend is Laravel 12 on PHP 8.4 with PostgreSQL, Redis, Horizon, Reverb, Scout/Typesense, Cashier/Stripe, Fortify, and Inertia Laravel v2. - Frontend is React 19 through Inertia React v2, Vite, Tailwind v4, Radix/shadcn-style UI components, Zustand for local builder state, Tiptap for rich text, and Vitest for JS tests. Request Flow: The documented flow is: nginx -> PHP-FPM -> Laravel routes/controllers/actions/services/models -> Inertia -> React Databases are workspace-owned structured data sources used by protocols and submissions. Async, Realtime, Search: - Queues use Redis/Horizon. AI work has queue-oriented services and telemetry. Reverb/Echo is available for realtime UI updates. Scout uses - Typesense for searchable models like protocols, inboxes, databases, users, and workspaces. PDF Generation: - Browsershot service registered into queue as for PDF generation. Avg pdf with 10-15 pages.