Building a Multi-Tenant SaaS Platform in India: Architecture Decisions That Matter

1 The Core Decision: Database Per Tenant vs Schema Per Tenant vs Shared Tables

The most important architectural decision in a multi-tenant SaaS platform is how you isolate tenant data at the database layer. There are three approaches, each with distinct trade-offs for Indian SaaS products.

For most Indian SaaS products serving SMBs (5–500 users per tenant), we recommend the Schema-Per-Tenant approach in PostgreSQL. It provides strong isolation, easier backup/restore per tenant, and simpler compliance (you can delete a tenant's entire schema on cancellation). The shared-tables approach with a tenant_id column is faster to build but harder to scale and presents data leak risks if WHERE clauses are missed.

2 Razorpay Subscription Integration: The Indian Billing Stack

Indian SaaS products cannot rely on Stripe — Razorpay is the dominant payment gateway with the best support for Indian payment methods (UPI, NetBanking, wallets) and GST-compliant invoicing.

For subscription billing, Razorpay Subscriptions handles recurring deductions automatically. We integrate this with a custom billing module that generates GST-compliant tax invoices (with HSN/SAC codes), sends them via email and WhatsApp, and syncs payment data to the accounting module. Failed payment handling includes a 3-attempt retry cycle with customer WhatsApp notifications.

• Razorpay Subscriptions API handles recurring UPI mandates and card auto-debit
• GST invoices generated server-side with GSTIN validation against the GST portal
• Failed payment → automatic retry + WhatsApp notification → grace period → suspension
• Prorated billing calculated correctly for mid-cycle upgrades/downgrades
• Revenue analytics dashboard showing MRR, churn rate, and ARR by plan

3 Authentication, RBAC, and Session Management

Multi-tenant SaaS requires a three-layer access control model: Organization level (which tenant), Role level (admin/manager/staff), and Permission level (read/write/delete per module). We implement this using Laravel's Spatie Permission package with PostgreSQL row-level security as a backup safety layer.

JWT tokens carry the tenant_id claim. Every API request validates the token, extracts the tenant, and sets the PostgreSQL search_path to the correct tenant schema before executing any query. This eliminates the possibility of cross-tenant data leaks at the framework level.

• JWT tokens carry tenant_id — every API call validates tenant context
• PostgreSQL search_path set per request to isolate tenant schema
• Spatie Permission package manages roles and permissions per tenant
• Super-admin role with cross-tenant visibility for platform operators
• Session expiry, device management, and audit logs built into auth module

4 Deployment Architecture for Indian SaaS on AWS

For Indian SaaS products, we deploy on AWS Mumbai (ap-south-1) region to satisfy data residency requirements and minimize latency for Indian users. The production architecture uses an Application Load Balancer → EC2 Auto Scaling Group → RDS PostgreSQL (Multi-AZ) → ElastiCache Redis → S3 (document storage).

CI/CD is handled by GitHub Actions. Every merge to main triggers automated tests, database migrations, and blue-green deployment to production. Zero-downtime deployments are critical for SaaS — we use AWS ECS rolling updates to achieve <5 second downtime windows.

• AWS Mumbai (ap-south-1) for data residency and low latency in India
• RDS PostgreSQL Multi-AZ — automatic failover in <60 seconds
• Redis ElastiCache for session storage, queue jobs, and API rate limiting
• S3 for document storage with pre-signed URLs (never serve files from app server)
• GitHub Actions CI/CD with automated test suite before every deployment