G'day,

This will be my first tech blog, so bear with me.

Previously I mentioned how we use Cloudflare workers to handle a large portion of our Elandra platform. If you haven't already, I highly suggest your read my Project Forever ISE blog post.

Let's break into the Bundler system. What is it?

It is a microtransaction bundler, enabling our system to recognise, identify, and bundle requests in advance but "smart". A bit of a mumbo jumbo, but I will explain how and why we are doing it.

Let's start with the why?

We have established that a returning user reconnecting to our system makes one request using 285 Bytes, and a single Cloudflare request is 4KB;. It would be very wasteful not to utilise the other 3.715KB.

• How wasteful?
  • If we had 2000 unique returning users onto our Elandra platform specifically to complete their homework, they would, on average, hit 5 pages. (10k requests per day), 20 weekdays a month; 200k requests.
    • 743,000KB worth, meaning we only utilise 7.125% of returning user requests.
• What is the 285 Byte request being made?
  • We are using Cloudflare Zaraz. We utilise this for all our third-party and internal tracking bundled into one.

How:

Due to the nature of our system, being modular, and how we handle internal requests, we can see every bit and byte that is required to create X.

• An example of X:
  • Student (Jessica) logins in on Wednesday; our system has already identified the next 7 days of homework module(s) and the required assets. All in all, 420KB.
    • 420 KB is broken down into 7 days. In this example, If the assets were evenly required across, it is (420/7) aka 60KB (15 requests).
• Recognise:
  • We can see there is potential to save requests being made, as our system is "smart" to predict the next 7 days of learning modules.
• Identify:
  • We have identified that Jessica could make 15 unnecessary extra requests per day.
• Bundle:
  • We could utilise Jessica's first return to Elandra and store assets in the browser's memory cache.
  • We could be bundling an additional 18.75KB of data.
    • Obviously, not all assets exactly fill that amount without going over.
    • We are averaging 84% fil (15.75KB) per day.
      • This will only get better once we define our fillers better.
  • 15.75KB * 5 requests * 7 days = 551KB threshold

Results:

For now, the bundler is averaging a 77% cost reduction overall. We expect better results in the future once our fillers work more efficiently/learn over time.

Cheers,

Byron