Unifying three portals on one messaging platform

Customer communication was scattered across phone calls and email threads belonging to three separate portals, each serving a different line of business. Nothing was searchable, context was lost between handoffs, and every question cost a support agent a synchronous interruption.

The three portals had to keep their own identities and their own front doors while sharing one message store underneath. That ruled out three separate implementations, and it meant the data model had to carry the line-of-business boundary rather than the deployment topology.

• Designed a single shared database backing all three portals, so a thread is one record regardless of which front door it arrived through
• Built the front end in Next.js and the services in Node on AWS Lambda, with MongoDB as the store
• Shifted the interaction model from synchronous phone and email to async messaging, so agents batch rather than context-switch

• ~10,000 messages per day
• ~6,000 daily users across the three portals
• ~1,000 support man-hours saved per month

I would put the read model behind an explicit projection from the start. Serving three portals from one collection was right, but the query shapes diverged by line of business faster than expected, and retrofitting indexes to match was more work than designing for it would have been.

• Next.js
• Node.js
• AWS Lambda
• MongoDB
• Tailwind CSS