REST API for international clients

Starting point

Provide a REST interface for international clients and make the required functions available through a shared API.

My contribution

My contribution was the technical implementation of the REST API. For comparable projects, I look beyond the endpoints at how requests are distributed, how client data is separated and how the system will be operated. One possible setup is described below.

What a scalable solution can look like

One possible approach for comparable requirements. Which building blocks fit depends on load, data flows and operating effort. The options below do not describe details already implemented in this project.

Scaling regionally

RequestsRouting & CDN

Cache for public content

Region AGo APIKubernetes

SQLiteper tenant

Region BGo APIKubernetes

SQLiteper tenant

Each tenant has a responsible region.

A possible approach, not an implemented project architecture.

Go services and Kubernetes

One approach is lean API services in Go (Golang). Stateless instances can be multiplied behind a load balancer; Kubernetes can take care of distributing them, restarting them and scaling them on demand. Data storage and background jobs are planned separately so that additional API instances do not simply move the bottleneck.

Edge computing with SQLite per tenant

With suitable write loads, each tenant can get its own SQLite database close to the responsible service. This makes separate data organisation and short local access easier. Routing and permissions must assign every request to the right tenant. Each database has only one concurrent writer, so replication, backups and recovery need their own concept.

Operating in several regions and countries

For internationally distributed users, the API can run in several regional Kubernetes clusters. Requests are routed to the responsible region. Data locations, write responsibility, replication lag and behaviour when a region fails all need to be clarified. Multiple locations alone guarantee neither consistent data nor uninterrupted operation.

CDN and targeted edge caching

A CDN can deliver static files and explicitly suitable public responses closer to users and relieve the backend. Cache lifetimes and invalidation determine how current the responses are. Personal or tenant-specific responses do not belong in a shared public cache.

Scaling with measurements, not assumptions

Load tests, response times, error rates and database utilisation show which building block is actually the limit. From this you can decide whether caching, additional instances or a different data store will help. Recovery and regional failures are also part of the operating concept.