Near every user
Users reach the closest region for their HTTP calls and WebSockets, wherever they are.
The framework for AI era
The framework for AI era
Level 5 · GlobalArchitecture 13 of 13
Every piece together: regions on several providers, customer data kept at home, shared state and one release flow.
The architecture large SaaS products grow into. Three regions on three providers serve users nearby, tenant databases stay in the region of their customers, and one API Maker DB and one Redis keep every region in step. Releases and events reach the whole world within seconds.
Every request is drawn as it travels. Slow it down, pause, go step by step, or open the full canvas and zoom in.
api-maker/architectures/global-enterpriseLiveOne platform: three regions, three providers. Users reach the nearest region, customers keep their data at home, and one API Maker serves them all.
The same steps as the diagram, in more detail.
This is where the other architectures lead: API Maker on plain VPS of three providers, one region per continent, each with a pair of load balancers and API servers. Tenant databases stay in the region of their customers, and the regions share one API Maker DB and one Redis through a private backbone.
GeoDNS sends each user to the load balancers of the nearest region, where the API servers answer HTTP calls and hold WebSockets. Every region serves the same APIs from the same API Maker DB, so it does not matter which one a user lands on.
The multi-tenant instance finds each tenant's connection string in the tenants table, and each tenant database runs in the region of its customer. Data residency rules are met by where the databases run, while one set of APIs, schemas and custom code serves every customer.
The home region runs API Maker DB, the MongoDB primary and a Redis Cluster for every region, reached through encrypted tunnels between the providers. An event raised in Singapore reaches WebSocket clients in New York and Frankfurt, and a write anywhere clears the cached responses everywhere.
Releases come from your Git repository, after DEV, QA and UAT. The pull runs on any one production server: the changes land in API Maker DB, and a cluster event through Redis makes every worker of every server, in every region, reload them within seconds.
Each region scales on its own: resize its VPS and restart them one at a time, and API Maker starts one worker per core, or add servers behind its load balancers. In our benchmark, six 8-core servers answer about 27,000 requests per second.
Users reach the closest region for their HTTP calls and WebSockets, wherever they are.
Each tenant database runs in the region of its customer, with the same APIs for every customer.
One provider per region: an outage, a price change or a new country is never a crisis.
DEV, QA and UAT first, then one git pull reaches every server of every region.
Events raised in any region reach WebSocket clients in every region through Redis.
Several projects share the servers, each with its own APIs, users, secrets and databases.
Plain VPS from any provider, or your own servers, with Ubuntu 22.04 LTS. Sizes are a starting point: measure and adjust.
Runs
Ports
Runs
Ports
Runs
Ports
Runs
Ports
Runs
Ports
Runs
Ports
username connection_stringacme postgres://app:***@10.30.1.40:5432/acme # Frankfurtglobex postgres://app:***@10.30.2.40:5432/globex # New Yorkinitech postgres://app:***@10.30.3.40:5432/initech # SingaporeAPI Maker keeps these connection strings encrypted in the table and decrypts them only to open a pool.
am__serverName="nyc-api-2" # region and server, to find it in the dashboardsam__cpuCount="AUTO"# The replica set over the three regions, the primary in Frankfurtam__mongo_db_connection="mongodb://api_maker:***@10.30.1.20:27017,10.30.1.21:27017,10.30.2.20:27017,10.30.3.20:27017/api_maker_db?authSource=admin&replicaSet=rs0"# Redis Cluster of the home region, for every regionam__redisInternal='{"nodes": [{host: "10.30.1.31", port: 6379, pass: "***"}, {host: "10.30.1.32", port: 6379, pass: "***"}, {host: "10.30.1.33", port: 6379, pass: "***"}]}'am__redisExternal='{"nodes": [{host: "10.30.1.31", port: 6379, pass: "***"}, {host: "10.30.1.32", port: 6379, pass: "***"}, {host: "10.30.1.33", port: 6379, pass: "***"}]}'Rarely at the start. Each piece comes from an architecture before it and can be added on its own: a second region, a tenant database in a new country, a third provider.
Yes. Copy its database to the new region, update its row in the tenants table and call the multi-tenant-instance-updated system API: every server resets its pool for that tenant.
As projects: each one has its own APIs, databases, secrets, users and roles on the same fleet, as the Multi-project architecture shows.