How I Scaled 16+ Enterprise Portals with AWS Centralized Microservices

March 15, 2025

When I joined Edelta Corporation in 2022, each enterprise portal was a silo — its own auth, its own search, its own deployment. By 2024, I had restructured the entire platform into a centralized AWS microservices architecture serving 16+ enterprise clients, including the ProtectAll Claims ecosystem (Claims, Work Orders, Dealer, Mattress, and Home Claims portals).

Here's the architecture thinking behind it.

The Problem: Silo Hell

Every client portal had:

  • Duplicate authentication logic with separate JWT implementations per service
  • No shared search — each portal queried its own database directly
  • Manual deployments — no CI/CD, no rollback, no visibility
  • Zero cost control — every portal ran its own EC2 instance at full cost

When we hit portal number 7, it became clear this wouldn't scale.

The Solution: 4 Centralized Microservices on AWS

I designed and built 4 foundational microservices that every portal now consumes:

1. Unified Auth Service

A single JWT issuing service deployed on AWS Lambda with an API Gateway. Every portal redirects authentication here. Session tokens are validated via a Redis cache layer to avoid hitting the database on every request.

Architecture Flowchart
Rendering diagram...

2. Universal Search Service

An EC2-hosted Node.js service with a PostgreSQL full-text search index. Portals send structured search queries; the service returns normalized results regardless of which underlying schema the data lives in.

3. PDF & Document Generation Service

Built on AWS Lambda + S3. Portals send a JSON payload; the service renders dynamic PDFs (claims reports, work orders, payroll slips) and stores them in S3, returning a pre-signed URL.

4. Notification & Workflow Relay

A Node.js service bridging AWS SNS and Zoho CRM webhooks. When a claim state changes in the CRM, this relay fires the appropriate portal notification or email workflow.

CI/CD: From Zero to Automated

Before: developers SSHed into EC2 instances to deploy.

After: every push to main triggers a GitHub Actions pipeline:

  1. Build — Docker image built, dependencies installed
  2. Test — Jest unit suite + integration smoke tests
  3. Push — Image pushed to AWS ECR
  4. Deploy — ECS task definition updated; rolling deployment with health checks
  5. Notify — Slack message on success or failure

Zero-downtime deployments. Rollback in under 60 seconds.

Results

MetricBeforeAfter
Deployment time45+ mins (manual)~4 mins (automated)
Auth code duplication×16 portals×1 central service
Monthly EC2 costsFull per portalShared + right-sized
Production incidents~2 per month<1 per quarter
Onboarding a new portal3–4 weeks3–5 days

The shift from siloed portals to a shared infrastructure model is what allowed us to take on new enterprise clients without linearly scaling the engineering effort.

Key Lessons

  1. Don't centralize prematurely — we waited until we had 5+ portals sharing the same problem before abstracting.
  2. Redis is your auth performance friend — validating sessions in-memory vs. database is a 10–50x latency difference at scale.
  3. Lambda cold starts hurt claims workflows — we moved the document generation service to a warm EC2 container after seeing cold start p99 latencies spike during claim filing peaks.
  4. Cost attribution matters — tag every AWS resource with the client identifier from day one. You'll thank yourself at billing time.

If you're building multi-tenant SaaS or managing multiple enterprise portals, the centralization pattern pays dividends. Start with auth — it's the common denominator.

GitHub
LinkedIn