AI · Document processing · Enterprise SaaS · Case study
Edge OCR: A multi-tenant AI document processing platform with usage-based billing
AI document processing SaaS case study: multi-tenant OCR on AWS Lambda with Redis queues, a MongoDB database per organisation and four Stripe plans.
- Client
- Edge OCR is a confidential enterprise SaaS product that extracts structured data from uploaded documents using AI-powered OCR.
- Team
- Full-stack development team
- Timeline
- Ongoing since 2024
- Services
- AI and data, Cloud and DevOps, Web development
- 1 per org
- Isolated MongoDB database per tenant
- 3
- Redis queues: processing, in-flight, dead-letter
- 4
- Subscription tiers with usage limits
- 7 + 3
- AWS services plus third-party platforms integrated
In short
Edge OCR needed a platform where organisations upload documents in bulk, get structured data back from AI-powered OCR, organise it into searchable collections and pay by usage. We designed and shipped it: a NestJS GraphQL backend, a Next.js frontend, a serverless extraction pipeline on AWS Lambda with Redis queues and a dead-letter queue, one isolated MongoDB database per tenant, and four Stripe subscription tiers. It runs on AWS ECS with an automated CodeBuild pipeline.
Where they started.
- Process high volumes of documents with accurate extraction while keeping every organisation's data completely isolated
- Show real-time processing status for jobs that run asynchronously, and never lose a failed job
- Support template-based extraction for known forms and free-form extraction for everything else
- Bill by usage across four plan tiers with monthly and annual cycles, overage purchases and scan rollover
- Make the workflow usable by non-technical staff who need to edit, organise and export results
The approach.
- Built a modular NestJS 11 backend exposing a GraphQL API through Apollo Server 4, deployed as containers on AWS ECS
- Designed multi-tenancy with a dedicated MongoDB database per organisation, dynamic model loading, per-tenant connection pooling and a circuit breaker on connections
- Implemented a three-queue Redis architecture: a processing queue, an in-flight queue to prevent duplicate work and a dead-letter queue for exhausted retries
- Ran OCR on AWS Lambda with template-based and free-form extraction, AWS Bedrock for document understanding and Adobe PDF Services for complex PDFs
- Integrated Stripe for Free, Starter, Growth and Scale plans with scan limits, overage purchases, rollover and full webhook handling
- Delivered a Next.js 14 frontend with drag-and-drop bulk upload, direct-to-S3 presigned uploads, Tesseract.js previews, Algolia search, collections, templates and CSV and PDF export
What shipped.
- Multi-tenant SaaS platform live in production
- Serverless document processing pipeline with queue-based reliability and GraphQL subscriptions for status
- Collections with configurable column schemas and record creation from processed documents
- Reusable document templates stored in S3 with metadata in MongoDB
- Four-tier subscription billing with Stripe webhooks, transaction history and invoices
- RBAC with resolver-level permission decorators, subscription guards and a security-log interceptor
- Automated CI/CD on AWS CodeBuild with Docker images in ECR and rolling ECS deployments
- Usage dashboards, queue monitoring and health-check endpoints
How the engagement ran.
Context
Edge OCR is an enterprise SaaS product for turning documents into structured data. Its customers upload forms, invoices and scans in bulk, expect accurate extraction, and need results organised into tables they can search and export. Because customers are separate organisations, data isolation is a requirement, not a feature. Because processing is heavy, it has to run asynchronously without losing work.
We were responsible for the complete product lifecycle: architecture, backend and frontend development, cloud infrastructure, integrations, CI/CD and production deployment.
A document's journey is short to describe and long to make reliable. It is uploaded straight to S3, recorded as pending, queued in Redis, picked up by a consumer that calls the Lambda OCR service, and written back as completed or failed while the browser watches the status change over a GraphQL subscription. Failed jobs never disappear; they wait in a dead-letter queue for a retry or a human decision.
What we built
- Single and bulk document upload straight to S3 through presigned URLs, with Tesseract.js previews in the browser
- AI-powered OCR on AWS Lambda with template-based extraction for known formats and free-form extraction for the rest
- Real-time status tracking from Pending through Queued, Processing, Completed or Failed, with result editing
- Collections that map OCR fields into configurable table schemas, with CSV and PDF export
- A template system that stores reusable form definitions and routes extracted data into collections
- Four-tier Stripe billing with monthly and annual cycles, scan tracking, overages and rollover
- Self-service organisation creation, team management, OTP email verification and Argon2 password hashing
- Scan history, usage dashboards with ApexCharts, queue monitoring and audit logging of every mutation
Architecture and stack
| Layer | Technology | Why |
|---|---|---|
| Backend | NestJS 11, TypeScript 5.7, Apollo Server 4 GraphQL | A modular monolith with typed resolvers and subscriptions for live status |
| Tenancy | MongoDB 8 with a database per organisation, dynamic models, circuit breaker | Complete data isolation and resilient connections |
| Processing | Redis and Bull queues, AWS Lambda OCR, AWS Bedrock, Adobe PDF Services | Asynchronous, retryable extraction that scales independently of the API |
| Storage and search | AWS S3 presigned uploads, Algolia | Browser-to-S3 transfers and search-as-you-type over documents |
| Billing | Stripe 18 subscriptions, payment intents and webhooks | Usage-based plans with overage purchases |
| Frontend | Next.js 14, Apollo Client 3, Ant Design 5, Radix UI, Tailwind CSS, React Hook Form with Zod | Server rendering plus a rich, accessible document workspace |
| Infrastructure | Docker, AWS ECS, ECR, CodeBuild, SSM Parameter Store, SES fallback | Automated builds, rolling deployments and managed secrets |
| Security | JWT with tenant context, RBAC decorators, subscription guards, Argon2, security-log interceptor | Every mutation is authorised, metered and recorded |
How we worked
We started with the two decisions that are hardest to change later: tenancy and the processing pipeline. Per-organisation databases were chosen over row-level scoping to make isolation structural, and the queue design was built to fail safely, with in-flight tracking and a dead-letter queue, before any OCR model was connected. The GraphQL schema then grew feature by feature: documents, collections, templates, billing and team management.
Environments were separated from the beginning: local MongoDB and Redis with hot reload for development, a reduced-capacity AWS staging environment for QA, and a multi-AZ production environment. Every push runs through CodeBuild, produces a Docker image in ECR and rolls out on ECS.
Security controls were layered rather than centralised in one place. Tenant context travels inside the JWT, permission decorators guard individual resolvers, a subscription guard confirms scan availability before any processing starts, and an interceptor records every create, update and delete with the entity type and client details. Secrets live in SSM Parameter Store and are injected at build time, never committed.
Scale and complexity
| Measure | Figure from the documentation |
|---|---|
| Tenant isolation | One MongoDB database per organisation plus a master database |
| Queue architecture | 3 queues: processing, in-flight, dead-letter |
| Subscription tiers | 4: Free, Starter, Growth, Scale |
| AWS services | 7: S3, Lambda, Bedrock, SES, ECR, ECS, SSM, with CodeBuild for CI/CD |
| Third-party platforms | Stripe, Brevo, Algolia, plus MongoDB Atlas and Adobe PDF Services |
| Extraction modes | 2: template-based and free-form, with client-side preview |
What this means for your project
Any product that runs AI over customer files has the same four problems: isolation, asynchronous reliability, accuracy across document types and billing that matches usage. Edge OCR is a worked example of all four, with the infrastructure decisions written down.
If you are scoping an AI document, data extraction or workflow automation product, we can start from this architecture and adapt the extraction layer to your documents rather than designing the platform from scratch.
What changed.
- Delivered a fully functional, production-ready multi-tenant SaaS platform from concept to deployment
- Bulk uploads are processed through a queue-based pipeline that captures failures for retry rather than dropping them
- Seven AWS services and three third-party platforms were integrated into one architecture
- Non-technical users manage document workflows, edit extracted values and export results without engineering help
Questions about this project.
What is the safest way to isolate customer data in a SaaS product?
Database-level isolation. Edge OCR gives every organisation its own MongoDB database, so a query cannot reach another tenant's documents even by mistake. A master database holds organisations, plans and security logs, and connections are pooled per tenant with a circuit breaker for resilience.
How do you keep asynchronous document processing reliable?
Jobs move through three Redis queues. New documents enter a FIFO processing queue, active jobs sit in an in-flight queue so nothing is processed twice, and jobs that fail after retries land in a dead-letter queue for review. Status changes are pushed to the browser through GraphQL subscriptions.
Can usage-based billing handle overages and rollover?
Yes. Each Stripe plan carries a scan limit; paid plans can buy additional scans, unused scans roll between billing periods according to the plan rules, and webhooks keep subscription state and transaction history in sync.