The Fastest Elephant in the World

The Elebase API delivers your responses with an ultra-fast global Content Delivery Network. That means that when a user requests data or files for your application, the data or files are served automatically from a CDN node nearest to and most efficient for the user.

In the old paradigm, a database request would go back to the database, where the request was assembled, and then returned to the user. If the exact same request was made two seconds later, the request would go back to the database, and it would get assembled all over again — as if the request two seconds prior had never happened.

Using Elebase, you can serve your data to your users in a much smarter way. When a request is made, the response to that request is delivered to your app and also distributed out to a global collection of servers called Content Delivery Network (CDN) nodes. If the same request is made (say, two seconds later), instead of going all the way back to the database, and going through all the work and time of assembling that same request all over again, the request is instead delivered from a CDN node that is nearby the user.

This means that your requests are delivered to your applications very quickly, and it also means that your applications can withstand significant volumes of traffic.

If you want to know more about how this works, read on.

The Elebase CDN has an intelligent, event-based, dependency-aware invalidation system that tracks changes to the data in your Projects and, within seconds, automatically invalidates all the cached responses affected by these changes across the entire global network. As of today, the average delay between the time a change is made and the time at which cached responses containing outdated information are no longer returned, is 4.8 seconds.

However, if you ever need to forcibly bypass the cache for a GET or HEAD request, a standard Cache-Control header can be included with the no-cache directive: Cache-Control: no-cache

Before using this header in production, it's important to consider that fresh API responses cost more than cached API responses, both in terms of performance and the associated usage charges. Thus, it's good practice to only include this header when you need to expressly prevent outdated information from ever being returned, and the short delay (around 5 seconds) between the time a change was made and the time at which cached responses are automatically invalidated is unacceptable. A common example would be a draft preview screen, which allows users to review their draft Entries before publishing them. Even a very short delay on a screen like this could be frustrating. Therefore, including the Cache-Control: no-cache header when retrieving the draft Entry in this context is a sensible thing to do.