Scale and performance
In this article, we will cover how the Didomi platform is designed to scale to your organization's needs and how optimize our technology to perform on your websites and applications.
Didomi platform scaling
In the sections below, we outline ways in which parts of the Didomi platform scales its technologies:
Script
Didomi JavaScript code is statically hosted on AWS S3 and served through Amazon Cloud Front with replication in all their points of presence in the world (including Spain). Didomi does not have any single server in that path, and we are confident that Cloud Front can scale without an issue.
The banner, the pop-up, and the tag management (firing any third-party tag that requires consent, the IAB CMP API, etc...) all happen without any server requests (consent is cached locally in a cookie) so that your organization's end-user experience is not impacted.
Back-end servers
Didomi sends HTTP requests when consent is collected or for counting page views (we sample the number of page views by counting between 10% - 20%). These requests are asynchronous and always happen after all the front-end operations so that, even if they were to fail, it would not impact the end-user. This also means that if Didomi servers were to be unavailable, the experience of your end-users would not be impacted and consent is stored locally and sent to our servers later on.
Back-end servers are monitored 24 hours a day, 7 days a week with alerting through New Relic and AWS CloudWatch to ensure that Didomi is notified if there is any issue. We auto-scale these servers to ensure that we add (or remove) servers to our stack as needed throughout the day or when we sign up new clients.
Typically, Didomi does not monitor clients individually (we might do it exceptionally from time to time) as we focus on making sure that all our infrastructure is elastic, can scale without any human intervention, and that our servers being down does not impact the critical path of collecting/managing consent for end-users. We know we can handle 10 times more traffic than we do today without any issue (and that growth has happened a few times over the last few months).
Didomi platform performance
The general rule at Didomi is an imperative to minimize the impact of our presence on websites. In order to achieve this we have implemented the following measures:
Use a CDN (AWS CloudFront) and aggressively cache our SDK to make sure that it is distributed as fast as possible anywhere in the world with local points of presence.
Minimize the number of HTTP requests that we send to our servers. The initial load (the first time an end-user loads our SDK) typically takes two HTTP requests and subsequent loads of the SDK do not require HTTP requests for consent management. We embed the geolocation of the end-user as well as any specific configuration for your websites into a website-specific version of our SDK to avoid extra round trips.
Cache all the consent information in cookies locally to ensure that we can answer consent requests on the page immediately. This means that we do not delay loading your ad tags by loading data from our servers.
For non-EU publishers, we stay out of the way for non-EU end-users as much as possible and immediately fire all the tags that we might be in charge of without any request to our servers. We load a specific version of our SDK that does not include all the UI components to be lighter in these cases: its only job is to fire all the tags as fast as possible. With some additional configuration, we can also avoid loading our SDK for non-EU end-users completely and have you setup Google Tag Manager in a way so there is no delay/condition for non-EU end-users.
The Didomi SDK is deployed with the "async" attribute to ensure that it does not block your content.
Last updated