Building a global SaaS is the dream. But as you expand into the Asia-Pacific (APAC) market, you quickly realize it's not one market, but dozens—each with its own customer expectations, performance challenges, and complex data privacy laws. A single, centralized architecture, no matter how scalable, simply won't cut it.

At Walla, we faced this challenge head-on. The decision to build a multi-region platform wasn't an afterthought; it was a foundational choice driven by our commitment to performance and compliance. It’s far more than just spinning up servers in a new location. It’s a fundamental shift in architecture, operations, and product thinking.

In this post, we'll share our five key learnings from building Walla Form's multi-region architecture for the complexities of the APAC market.

Learning #1: Multi-Region is a Product Decision, Not Just an Infrastructure Task

The biggest mistake a team can make is treating data residency as a purely backend or DevOps task. The ability for a customer in Singapore to choose a "Singapore data region" is a core product feature.

This decision impacts everything: the user interface (your settings page), your pricing tiers, your public API design, and your legal contracts (Terms of Service and DPAs). Your entire organization—from product and engineering to sales and legal—must be aligned. At Walla, our multi-region capability is a first-class citizen in our product roadmap, not just a line item on an infrastructure bill.

Learning #2: Separate Your Control Plane from Your Data Plane

To manage global operations efficiently while ensuring strict regional data isolation, we architected our system by separating two key components:

• The Global Control Plane: This is our centralized 'brain'. It's hosted in a highly available region and manages things that are global by nature: user authentication, account information, billing, subscription plans, and the form builder interface itself.

• Regional Data Planes: These are the isolated 'hands' that do the sensitive work. We have separate, self-contained data planes in key jurisdictions (e.g., Singapore, UAE). When a form submission occurs, the data is routed directly to the customer-designated regional data plane. This sensitive response data never passes through or is stored in our global control plane.

This hybrid model gives us the best of both worlds: global efficiency for managing the application, and strict regional isolation for handling customer data, which is the only way to truly solve for data sovereignty.

Learning #3: Data Gravity is Real—Co-locate Compute with Data

It's not enough to just store your database in Singapore if all your API servers and application logic are running in the US. The speed of light is a hard limit, and every API call would still suffer from high latency.

Our regional data planes are not just databases; they are self-contained pods with their own dedicated API endpoints and processing power. When a user in APAC interacts with their form responses, the entire interaction—the API request, the processing, the database query—happens within the low-latency regional environment. This is the only way to deliver a truly high-performance experience.

Learning #4: Design for "Dumb" Regions and a "Smart" Router

Building a bespoke, complex architecture for every new region you add is a recipe for technical debt and slow expansion. We adopted a 'stateless' or 'dumb region' philosophy.

Each regional data plane is a standardized, identical, and independent blueprint. The intelligence lives in our global routing layer. When a request comes to api.walla.my, our router instantly identifies which region the data belongs to (based on the project key or another identifier) and transparently proxies the request to the correct regional API endpoint (e.g., api.sg.walla.internal).

This approach allows us to spin up a new region (e.g., a future 'Australia' or 'India' region) with minimal engineering effort. We are simply deploying a standard, pre-configured template.

Learning #5: Compliance is an Ongoing Process, Not a One-Time Setup

Launching a new region is just the beginning. Each jurisdiction has its own ongoing requirements for monitoring, security, and legal oversight. We have region-specific logging, backup policies that ensure backup data also stays within the region, and distinct disaster recovery plans. Our legal and compliance team continuously monitors changes to laws like the PDPA to ensure our architecture, operations, and contracts remain fully compliant.

Conclusion: A Foundation for the Future

Architecting a multi-region SaaS for APAC is a complex but incredibly rewarding journey. It forces a level of discipline and clarity in thinking that strengthens your entire platform. Our biggest learning is this: a multi-region strategy is the ultimate competitive advantage in a world where performance, security, and data sovereignty are no longer optional.

Disclaimer: This article reflects our architectural approach and learnings. Every application has unique requirements, and this is not a one-size-fits-all solution.