Scaling Parloa: When the platform becomes the product

Parloa is growing fast. Every quarter, we onboard new enterprise customers, expand into new regions, and absorb voice minute volumes that would have looked absurd to us a year ago. The product continuously evolves to meet the expansion, and as it does, the platform underneath has to keep up. While the evolution is exciting, it’s not without its own set of technical challenges.

One of the most exciting challenges we recently faced was figuring out how we could avoid the problem baked into multi-tenant architecture, where one customer’s traffic surge or failure becomes everyone’s problem. 

The problem nobody talks about until it happens to them

Throughout my years as an engineer, I've seen versions of this story enough times to know how it ends.

A lighthouse customer runs a successful marketing campaign. Traffic surges. Their response latency starts climbing. They aren’t the only ones feeling it. A neighbouring customer's workload starts to degrade, too. Then another one’s. Within minutes, what started as one customer's success has become everyone's problem.

This problem has been coined the noisy neighbor antipattern, and in a traditional multi-tenant architecture, it's not a question of if it will happen. It's a question of when.

Werner Vogels, AWS's CTO, put it cleanly:

Vogel is not saying engineering teams can prevent failure, that’s unrealistic. He is saying that engineering's goal should be to contain it within a defined radius that restricts how far the failure travels and whether it impacts the customer next door.

Because while a latency spike is inconvenient for most software products, it’s detrimental to voice AI solutions. When a latency Service Level Objective (SLO) is breached, calls degrade and eventually break. A customer interacting with a voice AI agent hears silence, garble, or a dropped session. The experience is not recoverable with a "we apologise for the inconvenience" page, it’s just dropped. 

Enterprise customers also add their own expectations to voice solutions: dedicated resource guarantees, predictable availability under SLA, the certainty that one neighbour's bad day will not become their bad day, and the ability to roll back or patch errors without having to reconfigure the whole platform. 

These expectations aren’t unreasonable, but they do beg a question: If you're serving dozens of enterprise customers, some of them running enormous daily voice minute volumes across multiple regions and jurisdictions, how do you design a platform where one customer's bad day stays confined to only them?

Customer infrastructure in a box

The answer we landed on is deployment stamps. But before making sense of how stamps work, it helps to understand the platform they sit inside.

The Parloa platform is built on two planes:

• The control plane is the global brain of a customer’s Parloa platform. It’s where the orchestration logic lives and where the management surface sits. On the control plane, customers are able to configure their Parloa agents from anywhere in the world. 

• The runtime plane is where conversations actually happen and encapsulates our different channels like voice over RTP and SIP, WebRTC and multi-modal protocols. Because customer data lives on the runtime plane for the duration of a conversation, the plane is designed regionally, with residency, latency, and resilience metrics specific to that geolocation in mind.

The two-plane separation of Parloa’s platform is a key driver for reliability at scale. Because while the control plane is global, the regional design of the runtime plane keeps customer interactions isolated and shaped to the local conditions of each market. 

Stamps are how we slice each region's compute and storage into the customer-isolated units. They live inside the runtime plane. 

Microsoft's Azure Architecture Center, which is where the stamp pattern is formally documented, defines deployment stamps like this:

The way I like to describe a deployment stamp is "customer infrastructure in a box." It bundles everything a customer or customer cohort needs into one isolated unit: compute, AI capacity, quotas, networking, monitoring. What happens on one stamp stays on that stamp, so if there is an outage, no other stamps are affected. 

While the two-plane architecture of Parloa’s platform already delivers reliability, stamps add an additional layer of resiliency, customer-level isolation, and regional flexibility. They replicate across regions, eliminate local redundancy, and adhere to data residency compliance. Low-latency is accessible for customers in each geography. Stamps also enable Parloa to load shed traffic between regions when conditions call for it, providing us with flexibility and options, while maintaining reliability.

Shipping safer, not just faster

Here is a framing mistake I see a lot in conversations about shipping speed. People conflate deployment with release, and then optimize for the wrong metric.

Deployment is the technical act of getting code into production. We want to deploy constantly, and modern strategies (blue/green, canary, feature flags, rolling updates) are what make that safe. The platform team's job is to make deployment a non-event.

Release is when the customer actually starts experiencing the new behaviour. That is a different question, and in enterprise voice AI, it’s the one that matters most. A regression in a release lands as a degraded conversation someone is paying for.

Stamps alleviate the risk of release regression by isolating customer cohorts. We release a new feature to a small stamp first, watch how it behaves in real production traffic, and only then move it forward. If something surfaces early, we roll it back on that cohort only. The customers further down the release path remain unaffected.

With stamps, we find what breaks at a small scale, not at full scale, making them what actually accelerates time to customer value. We don’t just deploy more often, we release more safely. 

Finally, when a release is happening, customers can choose to stay on the stable side until validation completes. That option is part of what they are buying. It’s not a feature flag, but an architectural guarantee.

What this means for enterprise trust

Enterprises don't buy reliability promises. They buy trust earned through consistent execution.

We are not asking customers to bet on experimental ideas. We are applying architecture they already know and respect, and shaping it for voice AI.

With the deployment stamp advantage, customers know that their workload is separated from others on the platform. They have predictable resource guarantees backed by per-stamp quotas. They know which region their data lives in, and that, should something go wrong, the scope is smaller and faster to fix. 

SLAs are defined per service and per stamp, which means when we communicate an incident, we can say with precision: this is a stamp-specific issue, not a platform-wide event. That precision itself is a trust signal.

Where we go from here

The voice AI and agentic AI workloads we support today are different from what they were eighteen months ago. They will be different again in eighteen months. Parloa’s platform will continue to have to evolve with them. Neal Ford, Rebecca Parsons, and Patrick Kua call this evolutionary architecture: systems designed for constant change rather than for one moment in time. That framing matches how we think about Parloa's platform, and it is why building on proven, flexible foundations matters so much.

Global expansion is active work. With more regions and more cloud providers, deployment stamps are one way Parloa's platform strategy turns engineering decisions into customer outcomes. End users feel the transition directly through the reliability of their conversations and the speed at which we ship new value to them, building trust with the platform over time.