Following up on Nitro Boost Project Stage 1, stages 2 and 3 are now live! This had made Lifeboat one of the fastest e-commerce solutions available today!
This post will be a relatively technical one, but we'll try our best to oversimplify the changes.
We did a bunch of cool tech things to give you and your customers a much better experience when using Lifeboat. These changes made Lifeboat one of the fastest e-commerce platforms worldwide.
|Post-Nitro Boost Stage 1
|Post-Nitro Boost Stages 2 & 3
Server Response Time
Browser Loaded the HTML
|Full Site Loaded
Site is usable
Time browser has to wait between loading of resources
Note: Tests are performed within the EU, if accessing sites from outside the EU timings might vary.
So how did we do it?
One of the major bottlenecks in Lifeboat was that the internal systems were tightly coupled, the databases, web servers, and everything in between resided in tightly connected clusters. This made it easy for us to launch the MVP of Lifeboat but prevented us from properly scaling out. Cue in Amazon Web Services. Our databases now live in a "serverless" environment that can quickly scale to meet traffic demands. As from our testing any Lifeboat site can now easily handle hundreds of thousands of concurrent users.
The database was not the only issue though, the web servers also need to speak what we internally call "the morphing language", which in its most basic form means; any server in our cluster could respond to a request irrelevant to the store domain. Because under the hood we use a framework "Silverstripe" this wasn't the easiest of challenges (far from it). However, after a bit of tweaking with how configurations are loaded, and how content was rendered we managed to configure this "morphing" system. To simplify; if a Lifeboat store gets a spike in traffic, other servers can quickly come pitch in to help spread the load and offer a consistent experience.
But what does it mean for the average merchant?
Think of it this way, where we previously reserved a chunk of capacity per site leaving us with a lot of wasted resources, we now have a dynamically expandable pool of resources. If a site gets a sudden spike in traffic this pool automatically configures itself to bring more machines online to handle this load. This gives your end customers a stable and performant experience irrelevant of how many users are online.
To be able to effectively distribute traffic, we also had to deploy a new system to balance the load. Cue in HAProxy. Without going into too much detail (for security reasons), this new system can handle hundreds of millions of requests, and like a traffic light system, it directs customers to the webserver best equipped to serve the request at that time. This new system also means we can now offer much more protection against DDOS, and malicious bots.
Finally, the last piece of the puzzle was changing how he store and retrieve data to extract as much performance from the new available systems. For obvious reasons, we can't go into detail on how this is done however, we can share that by optimising our storage systems, and data structures we managed to reduce the amount of data queried by ±70%!
The topics in this article are a bit tricky to explain however, the results are simple to explain. Thanks to the dedication of the dev team, Lifeboat merchants and customers can enjoy an improved experience when using Lifeboat.