EveryTech

Social Commerce

Scaling chat capacity on a social-commerce platform

An EveryTech principal consultant helped scale a social-commerce platform past 10 million registered users and increase simultaneous chat capacity from 100,000 to 1 million. AWS documented the capacity increase.

· 1 min read

A consumer social-commerce platform at hypergrowth stage, running a social feed, a merchant marketplace, and a rewards economy inside one app. EveryTech's role was principal engineering leadership through the platform's steepest growth period.

Problem

The product grew faster than the architecture it launched on, and chat was where users felt it first. When concurrency climbed, messages queued or arrived out of order, and the failure was visible to everyone in the conversation rather than buried in a dashboard.

The design treated chat as one feature among many rather than as its own capacity question. Connection state, message fan-out, and media delivery drew on the same headroom as the rest of the platform, so a surge in one surface degraded the others. Every growth forecast put the ceiling nearer than the last one had.

Impact

  • An EveryTech principal consultant helped scale a social-commerce platform past 10 million registered users.
  • An EveryTech principal consultant helped increase simultaneous chat capacity from 100,000 to 1 million. AWS documented the capacity increase.

The capacity result is not self-reported. AWS published it in its own customer case-study library, and the archived copy is linked below.

Solution

Chat was rebuilt around simultaneous connections as the unit of capacity rather than requests per second. That change of measure did most of the work, because it replaced an argument about opinions with a target that could be load-tested and budgeted.

The workloads that had been competing for the same headroom were then separated onto managed services. Transactional data, event-driven work, long-lived services, and media delivery each got their own path, so a surge in one no longer pulled capacity from the others. The rebuilt system ran on Amazon Aurora, AWS Lambda, Amazon CloudFront, Amazon EKS, and AWS Elemental MediaConvert.

Capacity problems are often definition problems in disguise. This platform had been scaling against a measure that did not describe its real limit, so the work kept missing. The same failure recurs in AI programs, where a pilot that performs in a demo and stalls on the way to production has usually been measured against something other than the thing that will break.

Evidence