Blobr can actually be divided into two parts sitting on different infrastructure types:
Blobr Dashboard and Blobr API Portal
The dashboard is used to connect APIs, create API products, add customization options etc. The API portal is used to display API products and onboard your users.
Those two different interfaces are deployed in seven locations and are available everywhere in the world. Those two interfaces are completely unrelated to the Blobr API proxy.
Blobr API Proxy
This is the tech part enabling access to API users. There is geo-redundancy of the API proxy with idempotency. This means that the proxy behaves in the exact same way, whatever the region. AWS checks every 3 seconds which of the deployed regions is responding the fastest.
As a consequence, by design, the maximum consequence of an SLA problem would be 3 seconds consecutively as there is a fallback mechanism moving from one API proxy to another in case of a longer response time. The proxy is only based on one function and updates are extensively tested beforehand. In the worst-case scenario, if there are bugs in the Blobr API provider interface, the API proxy is still able to manage as per the rules.
At Blobr, we have created a build factory with automatic tests, executed everyday. We push our developments to production only when we have 100% success on the tests. The production workflow is even further tested as it is redirected to pre-production to perform additional testing on new features we release before it gets to production environment.