Home/Solutions
SOLUTIONS · FOUR REFERENCE ARCHITECTURES

Four ways to go global,
provisioned from a diagram

Cross-border e-commerce storefronts, games going global, multi-region SaaS delivery and AI inference services. Each solution comes with an architecture diagram, a product combination, recommended configurations and implementation steps you can follow directly in the console.

Get a custom design from an architectSee how customers use it
01 / CROSS-BORDER ECOMMERCE

Cross-border e-commerce storefront

Store systems and operations tools live in the target market, a native IP is the entry, managed MySQL carries orders; snapshot before sales and scale peaks by the hour.

Problems to solve

  • The storefront, payment callbacks and logistics APIs need a local IP entry in the target country, which generic cloud IPs are not registered as.
  • The store runs in a region far from its buyers, so first paint is slow and conversion suffers.
  • Sale traffic is 5 to 10 times normal; buying machines for the peak all year is too expensive.
  • There is no reliable rollback point for the order database when a mistake or a bad release happens.

Product combination

Global Cloud HostFlagship 4C8G × 2, Web / API pair across two zones$86.11 / month · instance (Singapore)
Native IPNative IP of the target country bound to the public entryTiered by country
Cloud Database MySQLHA 2C4G for orders, products and inventoryQuote
Cloud DiskRSSD 200 GB data disk, automatic backups + pre-sale snapshotsPer GB · month
Shared bandwidth package100 Mbps shared across the stores' IPs at peakMbps · month
BuyersNative IPSingaporeVPC · Singapore zone BWeb / APIFlagship 4C8GWeb / APIFlagship 4C8GCloud databaseMySQL 2C4GRSSD data disk · pre-sale snapshot

Implementation steps

  1. Create a VPC in the target market's region and launch one Flagship 4C8G in each of two zones.
  2. Request a native IP of that country from the IP pool, bind it to the entry instance and add a 100 Mbps shared bandwidth package.
  3. Create an HA MySQL 2C4G, whitelist the application subnet and import the order database.
  4. Enable automatic backups on the data disk; snapshot manually before a sale and add instances by the hour during it.
  5. Allow only 443 and your operations sources in the security group, and push monitoring alerts to the on-call channel.
Provision this solutionSee a real case
02 / GAMING

Games going global

Dedicated PRO game servers deployed in several regions by player distribution, 25 GbE private network for room sync, hot upgrades at launch peaks without downtime.

Problems to solve

  • Shared vCPUs get preempted by neighbors and frame sync jitters.
  • A single-region deployment leaves distant players above 150 ms.
  • Launches and events need temporary capacity; scaling with downtime loses players.
  • Accounts and data must be unified across regions while players connect nearby.

Product combination

Global Cloud HostDedicated PRO 8C16G, from 4 per region, dedicated vCPUsQuote
Global regionsSingapore, Tokyo, São Paulo and more, chosen by player distribution27 regions
Native IP and bandwidthPremium-line entry IPs, shared bandwidth packages absorb peaksTiered by country
Cloud Database MySQLAccount and data hub, HA 8C16GQuote
PlayersSE AsiaPlayersEast AsiaSingaporeGame servers × 4Dedicated PRO 8C16GTokyoGame servers × 4Dedicated PRO 8C16GBattle / matchmaking25 GbE private syncAccounts and dataCloud Database MySQL

Implementation steps

  1. Pick 2 to 3 regions by player distribution, one VPC per region.
  2. Launch 4 Dedicated PRO 8C16G game servers per region and freeze them as a custom image for adding servers.
  3. Bind a premium-line entry IP per region and size the shared bandwidth package to peak concurrency.
  4. Put the account and data hub on HA MySQL, reached by every region's game servers over the private network.
  5. Hot-upgrade CPU and bandwidth before launch, scale down after the event; watch CPU and PPS with monitoring alerts.
Provision this solutionSee a real case
03 / SAAS

Multi-region SaaS delivery

Freeze the runtime as a custom image copied across regions, provision a dedicated VPC environment per customer in bulk through OpenAPI, deliver in 20 minutes.

Problems to solve

  • Customers require data to stay in their region, so a copy is needed in several countries.
  • Manual deployment per new customer takes 2 to 3 days and environments drift.
  • Customers need network isolation from each other with unified monitoring and operations.
  • Growing customers must scale up smoothly without reinstalling.

Product combination

Global Cloud HostFrom Flagship 2C4G, one instance and VPC per customer, resized as they growQuote
Custom imagesBuilt once, copied to every delivery regionIncluded with cloud hosts
OpenAPICreation, resizing and reclamation wired into your operations systemAPI reference
Cloud Database MySQLDedicated instances for large customers, per-tenant databases for small onesQuote
Native IPEntry IP in each customer's countryTiered by country
Ops platformOpenAPI callsCustom imageCross-region copyHong Kong · customer AFlagship 2C4G, own VPCFrankfurt · customer BFlagship 4C8G, own VPCLos Angeles · customer CFlagship 2C4G, own VPC

Implementation steps

  1. Install the standard environment in one region, turn it into a custom image and copy it to every delivery region.
  2. Connect your operations system to OpenAPI: a signed contract creates the VPC, instance and IP and writes the customer configuration.
  3. Large customers get a dedicated MySQL instance; small ones get per-tenant databases on a shared HA instance.
  4. Route all monitoring alerts to one place, tagged and grouped by customer.
  5. Customer growth goes through the resize API without reinstalling; cancellations go through the reclaim API with snapshots kept 30 days.
Provision this solutionSee a real case
04 / AI INFERENCE

AI inference services

GPU type G for inference, Flagship for the gateway, model files on cloud disks, billed daily or hourly and released in traffic troughs.

Problems to solve

  • Inference traffic swings 10× between day and night; a GPU rented by the month sits idle most of the time.
  • Every scale-out re-downloads tens of gigabytes of model files.
  • The inference entry exposes GPU instances directly with no authentication or rate limiting.
  • Users are overseas, and half the inference latency is network.

Product combination

GPU Cloud HostG4 · T4 16 GB × 2, hourly, released in troughs$260 / month · instance
Global Cloud HostFlagship 4C8G as the API gateway: auth, rate limiting, routing$86.11 / month (Singapore)
Cloud DiskRSSD 500 GB model disk, snapshot-cloned to new instancesPer GB · month
Global regionsRun inference in the region of whichever area your users are inGPUs in stock in 4 regions
ApplicationsAPI gatewayFlagship 4C8GInference instanceGPU G4 · T4Inference instanceGPU G4 · T4ModelDisk

Implementation steps

  1. Create a VPC in a GPU-in-stock region of your users' area.
  2. Launch one G4 from the CUDA image, download the model to an RSSD model disk and snapshot it.
  3. Clone the model disk from the snapshot for a second G4 and start vLLM / Triton with docker run.
  4. Use a Flagship 4C8G as the gateway and expose only its elastic IP; restrict the GPU instances' security group to the gateway.
  5. Trigger the API to add or remove instances on GPU-utilization alerts, down to one instance at night.
Provision this solutionSee a real case

Not one of these four?
Let an architect draw yours

Send us your business model, user distribution and budget, and within 1 business day you get a design with an architecture diagram and a quote.

Talk to an architectTry one instance first
  • 1 business dayDesign and quote response
  • 1-on-1Architecture consulting and migration drills
  • 24×7Technical support after launch
  • SLA credits99.95% availability commitment