Serving your users globally faster

Serving your users faster globally

The emergence and the fast growth of Mobile Apps, Web Apps, Single Page Apps and APIs within the past few years is a telltale sign of the growing importance and demand for speed and faster user experiences by users. And this is not simply a psychological need for speed in our ever accelerating and connected world. It is a requirement.

• Faster apps lead to better user engagement.
• Faster apps lead to better user retention.
• Faster apps lead to higher conversions.

Despite the ever-accelerating pace of life, our reaction times remain constant, regardless of the type of application (online or offline), or medium (laptop, desktop, or mobile device).

For an application to feel instant, a perceptible response to user input must be provided within 10s of milliseconds. After a 1/2 second or more, the user’s flow and engagement with the initiated task is broken, and after 3 seconds have passed, unless progress feedback is provided, the task is frequently abandoned.

Simply put, speed is a feature!

There are a number of technical solutions for improving an application’s performance, such as the data transfer capabilities of servers or routers, including compression and streamlining application roundtrip responses. But there is one thing that cannot be addressed with technology, and that’s proximity.

Solving Latency with Geography, Not Technology

Given the above, the most practical solution is to move the data geographically closer to the customer or end points for a business. This is the concept behind Content Delivery Networks (CDN) and caching sites. Most get deployed on the edge to provide faster access to common, or popular data and they bypass the ‘speed of transport network’ issues by getting popular content to the edge, where the customers are.

But CDN's were created to solve the problems of the "old web" - a web that was static and relied heavily on server-side rendering. They don't provide much for SaaS providers. SaaS applications are powered by query driven, dynamic data - and CDNs don't do well with dynamic data.

Macrometa brings the CDN into the cloud-native era by providing a global multi-model database and geo-replicated streams at the CDN edge. It means your apps always run on the edge with nothing to cache, purge or expire. The edge is the dynamic origin for every request and your users are always served the freshest state from the closest edge PoP.

Simply put, we may not be able to make the packets travel faster, but we can reduce the distance your dynamic data has to travel. This empowers you to serve your customers globally at high speed by enabling your Apps & APIs to utilize dynamic data in close proximity to your customers.

Maintaining State at the Edge

Given the benefits associated with making state (i.e., dynamic data) available in close geographical proximity to users, why don’t we see developers doing this? It is because maintaining state (i.e., dynamic data) at the edge across several locations is a very hard problem especially when one needs various consistency guarantees on that data.

It takes years and a team of engineers with deep expertise in distributed systems & databases to build this type of fast data platform. If you have the time, money, energy and skills then you can certainly build a multi-modal fast data platform like Macrometa. The industry can certainly benefit from more data platforms like Macrometa’s fast data platform that are coordination-free and utilize both consensus and convergence mechanisms.

On other hand, if your primary focus is in building Apps and APIs for your business needs. then the Macrometa platform can definitely help you serve your customers globally, at high speeds - thus fairly quickly, by providing a geo-distributed fast data platform with various consistency guarantees and other functionalities.

Building a Global Address Book App

Let’s create the backend for an Address Book app in the next few minutes. An app that is available globally at high speed (i.e., local read-write latencies) to its users by leveraging Macrometa’s fast data platform.

I have highlighted the words next few minutes in the above paragraph because typically doing the same exercise without using Macrometa’s platform will take months to build it (assuming the team has necessary expertise). Don’t take my word though. Verify it for yourself.

Let’s build a simple geo-distributed backend engine for an AddressBook app in 3 simple steps.

Step-1: Login to Macrometa Fast Data platform

Once you login, you should see a dashboard similar to the below:

The pin icons on the map represent all the locations to which the data will be automatically replicated and converged in a deterministic manner. Applications can read and write locally from all these locations.

Step-2: Create an Address Book collection

Collections in Macrometa’s Fast Data platform (aka C8) are like tables in an RDBMS database. A collection contains zero or more documents. C8 is schema-less.

You can read more about various data models supported by C8 here.

Let’s start by clicking the COLLECTIONS menu entry, then the Add Collection tile. Give it a name, e.g. addresses, leave the other settings unchanged (we want it to be a document collection) and Save it.

A new tile labeled addresses should show up, which you can click to open.

Step-3: Generate CRUD REST API (RESTQL)

Let’s assume the document format for storing the address is as follows:

    {
      "firstname": "John",
      "lastname": "Doe",
      "email": "john.doe@macrometa.io",
      "zipcode": 56703
    }

Click the QUERIES menu entry to open C8QL query editor. Then create the following query :

Execute the query to make sure it works correctly. Then click on Save button and let’s save the query with name addAddress. This query then automatically will be available for execution globally by its name addAddress. In short, within a second you have a globally distributed backend service for this functionality in your app. Simple... Isn't it?

Let’s write queries for the other server side capabilities we need in our AddressBook app. Save them with relevant names as follows:

Name: addAddress

    INSERT { firstname: @firstname, 
            lastname: @lastname, 
            email: @email, 
            zipcode: @zipcode }
       INTO addresses

Name: getAddresses

    FOR address IN addresses
        RETURN address

Name: updateEmail

    UPDATE { _key: @key }
      WITH { email: @email }
      IN addresses

Name: removeAddress

    REMOVE { _key: @key} 
      IN addresses

After saving the queries, clicking on Queries and the GUI should show something that resembles the below screenshot.

Execute RESTQL API

Click the SUPPORT menu entry and open the API Browser. Scroll down and to see RESTQL api.

You can execute these RESTQL API from anywhere in the world. The Macrometa fast data platform will take care of intelligently routing the request to the location closest to your app, and return results from that location.

To see in action, let’s execute our getAddresses API using curl command.

Macrometa’s fast data platform routed the above request and executed in LosAngeles, US datacenter as that is closest to my current location (Macrometa is based in Palo Alto).

Intelligent Traffic Geo-Routing

Let’s see how much data geo-proximity matters. Below is a sample of lag times that will be experienced by your app users, with and without your data being available close to your app location. In my case, the app is the curl client.

When dynamic data is available close to the app:

When dynamic data is not available close to the app:

Needless to say, without dynamic data not being available close to your users, the lag times and experience of your app users will be very different depending on where they are located.

Wrapping up…

Faster apps lead to better user engagement, better user retention and higher conversions. The most practical solution is to move the data and application geographically closer to the customer or end points for your business.

Macrometa’s fast data platform enables dynamic data to be used like CDN by providing a global multi-model realtime database and geo-replicated streams at the edge. It means the backend for your apps always run on the edge with nothing to cache, purge or expire. The edge is the dynamic origin for every request from your app and your users are always served the freshest state from the closest edge PoP.

I hope the above shows how quick and easy it is to create a geo-distributed backend engine using Macrometa for your app to serve your users faster globally.

LOVE IT, HATE IT? LET US KNOW