A rental platform can have one public brand and several regional backends. The difficult part is making every request, device event, and operational action follow the same regional assignment.
We have been working through that design question for CoreCharge Cloud: how should a QR-based rental platform expand into additional regions while keeping regional business data and operations within defined boundaries?
This is an architecture proposal, not a report of a completed multiregion rollout. The hostnames and identifiers below are illustrative.
Start with ownership, not the visitor's IP address
Imagine a station assigned to a US workspace. A visitor scans its QR code while using a VPN with an overseas exit node.
The station's orders should still go to its assigned workspace. Moving them because the visitor's apparent location changed would make payment reconciliation and device control unpredictable.
Give the workspace, station, and QR route an explicit regional assignment. Use that assignment to find the service responsible for the rental.
Geolocation can help with public content or a first-time region suggestion. It should not silently reassign existing business data. AWS documents that DNS geolocation uses IP-to-location mapping and can receive queries it cannot locate.
DNS also does not inspect the device identifier in an HTTPS URL path. If a shared QR hostname needs to resolve a station to its assigned region, an application-level routing component must perform that lookup.
Keep the public entry small and the regional stack complete
The approach we are evaluating is a shared multitenant deployment within each region, with independent business resources between regions.
This follows the broad idea of the Deployment Stamps pattern: repeat a group of application and data components for a defined set of tenants.
For a rental platform, the regional boundary needs to include more than a web server:
| Component | Regional responsibility |
|---|---|
| H5 and admin APIs | Handle the assigned workspace's business requests |
| Identity and sessions | Apply the region's account and access model |
| Database, cache, and queues | Keep operational state within the intended boundary |
| Device gateway | Receive events and deliver commands for assigned stations |
| Payment integration | Handle callbacks, refunds, and reconciliation for local orders |
| Files, logs, and backups | Follow the same documented location and access policy |
The public website can remain a shared explanation of the product. A global region directory can remain small. Neither needs to become a central copy of every customer, order, or support attachment.
Within a regional deployment, tenant authorization is still required. Regional separation does not replace brand, merchant, role, or object-level permissions.
Follow one scan all the way to storage
A new QR code could point directly to a regional address:
https://us.rental.example/q/opaque-entry-id
The intended request path is:
QR scan
-> assigned regional H5
-> regional API gateway
-> regional business services
-> regional database, cache, queues, and files
The frontend can use a same-origin path:
const response = await fetch('/api/rental-context');
The regional web gateway must then route that path to the corresponding regional backend. A relative URL makes that configuration easier to manage; it does not prove that the gateway or its dependencies are correctly configured.
A regional page can still send requests elsewhere if its build contains an old API hostname. Review API, upload, WebSocket, authentication, telemetry, and third-party SDK destinations together.
The backend must also verify the authorized workspace, region, and target object. A region dropdown, client-supplied header, or CORS policy is not an authorization boundary.
Include the device connection and payment callback
Two important paths continue after the browser stops waiting.
The station needs a device gateway that matches its assignment. Its release, return, and connectivity events should reach the services responsible for its orders. Changing a DNS record will not move an already established TCP or MQTT connection; reconnect behavior needs a planned rollout.
The payment provider also needs the correct callback destination. Sending every webhook to a central service and forwarding it across regions can undermine the intended boundary.
Callbacks need signature verification, idempotent processing, and a way to identify the owning order. Refund and reconciliation jobs need the same assignment. A delayed callback should not cause two regional systems to process the same financial action.
Placing our integration service in a region does not determine every processing location used by an external payment or notification provider. Those dependencies need their own documented scope.
A region selector changes context; migration changes ownership
The admin experience can resemble a cloud console:
Region: US Workspace: Brand A / US Environment: Production
Devices | Orders | Merchants | Payments | Reports
Switching the selector should open an authorized workspace in the target region. It should refresh permissions, invalidate old workspace queries, and prevent stale forms from acting on the previous region.
The region and workspace should remain visible on order details, exports, refunds, and device-control confirmations. Multiple browser tabs make that context especially valuable.
Changing a workspace's assigned region is a different workflow. It requires migration, validation, and a cutover plan. A dropdown should never imply that existing data has moved.
For onboarding, the proposed sequence is:
- Choose the operating country and an available regional workspace.
- Explain the selected data location and external-service scope.
- Continue to that region before collecting workspace-specific personal details.
- Create agents and merchants within the workspace's authorization model.
A renter scanning a station generally should not need to choose a data region. The station already supplies that context.
Treat migration and recovery as explicit designs
Old QR codes may pass through short-link services, redirects, or legacy proxies. Keeping the printed code can be useful, but inspect the complete chain. A final regional URL does not tell us which earlier services processed request metadata.
Migration also needs to account for active rentals, payment references, device reconnects, delayed events, files, logs, and retained backups.
After the target region accepts new orders, rolling back is more involved than pointing DNS at the old database. The plan must preserve one authoritative system and reconcile the writes already accepted.
Recovery has the same constraint. If the documented boundary requires regional processing, a global failover rule should not silently send business traffic to an unapproved destination. Recovery locations and exceptions need to be agreed in advance.
What would make the proposal testable?
Before calling a new region ready, we would want evidence that:
- a scan reaches the intended H5, API, upload, and WebSocket destinations;
- backend dependencies use the intended regional resources;
- changing a region header or object ID cannot cross workspace permissions;
- device release and return events correlate with the correct order;
- duplicate and delayed callbacks do not duplicate financial actions;
- switching admin regions clears stale operational context;
- backups can restore a usable environment within the allowed boundary;
- logs and support exports follow the documented access rules.
A health endpoint can show that a service is running. These tests establish whether the business boundary works.
The practical starting point is one additional regional deployment, a small controlled pilot, and reusable deployment configuration. Global database replication and a complete infrastructure rewrite do not need to be the first step.
For CoreCharge Cloud, the product goal is to make shared-device operations understandable as they expand. Explicit workspace ownership helps connect the renter's scan, the operator's dashboard, and the services responsible for each order.
If you have moved a transactional SaaS from one region to several, which dependency was easiest to overlook: identity, callbacks, device connections, logs, or backups? How did you prove the boundary worked?
Disclosure: I work on CoreCharge Cloud. This article adapts our internal architecture planning into a public engineering discussion and was prepared with AI assistance. The proposed regional deployment and UI are not presented as shipped features. Regional hosting is one technical control; this article does not claim legal compliance, universal country availability, or a completed data-residency guarantee.
Top comments (0)