Stellar ForgeStellar Global Supplies came to us needing a single order management system. Eighteen months later, they're running 16 connected applications — order management, billing, analytics, an advertisement platform, AI-driven workflows — all handling over 2 million requests a month with 99%+ of traffic encrypted end to end.
It didn't start as a platform
The first build was small: track orders, generate quotes, done. The architecture decision that mattered most wasn't a clever piece of tech — it was refusing to hardcode assumptions that only held true for that one app, so the next app could plug into the same data layer instead of duplicating it.
Where the traffic actually comes from
Requests span more than a dozen countries, with the US, Singapore and the UK leading. That geographic spread is exactly why the caching layer sits at the CDN level rather than the application server — a request from Singapore shouldn't have to round-trip to an origin server on another continent to get a cached response.
What broke first
Not the database. Not the frontend. The first real bottleneck was synchronous jobs — billing calculations that blocked the request thread instead of running in the background. Moving those to a queue was a bigger performance win than any server upgrade.
The architecture principle that held up
- Shared authentication and data layer across all 16 apps, so new tools don't start from zero
- CDN-level caching for anything that doesn't change per request
- Background jobs for anything that doesn't need to block a user's screen
- Monitoring from day one, not bolted on after the first outage
None of this is exotic. It's the same handful of decisions, applied consistently, as the platform grew from one app to sixteen.