Q&A with Fastly – Preparing for Peak
As we approach a critical time for retailers, it’s clearer than ever that this year is simply like no other. During lockdown we’ve seen demand spike for an unusual range of products – including pizza ovens and DIY materials – putting more pressure on sellers to be geared up for demand.
As we enter the so-called Golden Quarter, looking ahead to Black Friday and Christmas, we’re thinking about what to expect in the coming months – and wondering how can we predict the unpredictable?
thinkTRIBE invited Julien Maingard, Sales Engineer Manager from edge cloud platform Fastly, to discuss how to plan for success when preparing for peak.
Q: How will this peak differ from previous years
A: The e-commerce space has boomed during the last six months, with many companies having to launch or step up their online presence. Peak windows are normally closely aligned with sales seasons. But with more businesses engaging online – rather than in store – transactions are being extended to include a greater range of products. Even organisations like educational and medical suppliers are having to extend their platforms and services to deliver more online options than they would have previously considered.
Q: What do businesses need to look out for ahead of peak?
A: Performance and scale are the two main priorities – both are essential if your users are to enjoy a positive experience. Your service needs to be available, even during peak periods, when increased volumes, additional requests and bigger product numbers make it tougher to deliver a trouble-free journey. It’s important to understand where your bottlenecks are by spotting them early and remedying them quickly.
Consider your key markets, as well as any emerging hot spots that could increase the pressure on your resources and think carefully about the devices you support to keep on top of the user experience across different devices.
Be aware that browsing behaviour and buying behaviour use up resources very differently. Typically, browsing behaviour can be sustained by ensuring pages and images stay up via caching. But when shoppers enter the buying mechanism, a different set of back-office applications and resources come into play and bottlenecks can quickly form. Understanding the profiles of those various resource usages is going to provide a much better understanding of how your application is likely to hold up during peak traffic
Q: As more people are engaging with online shopping – some for the first time – how can businesses predict what these purchase journeys will look like
A: You have to use realistic testing to understand your application inside out. Utilise synthetic and real user traffic. Leverage the experience of your peers and any third parties that you’re working with to help you understand where weaknesses may lie. The right kind and frequency of testing will give you a solid basis for discovering all the pinch points in your application and will give you the confidence and assurance that you’re on the right track.
Q: How does using an edge cloud platform like Fastly help retailers prepare for peak?
A: We’re here to take on the load and scale customers’ applications, effectively handling the bulk of the traffic load. We recommend caching as much as you can – even your dynamic pages – to reduce bottlenecks. With Fastly, even things that you couldn’t cache before can now be stood up on a CDN capable of handling a huge volume of simultaneous users, which takes the pressure off your application. Any redundancies that you have in your back-office application can be used as resources in a load balancing pool to help your application stand up for longer. Which means that your application can scale almost instinctively, according to available load.
Resource efficiency is key: if you’re serving two different device types, for example, make sure that you’re resizing images to match that device, lessening the required bandwidth and, at the same time, creating a tailored experience for each user.
Q: How do you view performance testing through CDN versus testing direct?
A: Load testing via CDN can be a poor use of resources. CDNs are generally designed to scale to huge amounts of volume so throwing a ton of traffic synthetically at a CDN that is designed for the task won’t really return a lot of useful information on the location of bottlenecks in your application. It’s when you’re trying to find gaps in the delivery and you’re looking at things like your database, connections to the origin and the amount of bandwidth that the origin is provisioned to deliver out. Those are the things that a single serving infrastructure can’t scale very well. What you really want to do with a load testing strategy is to hit the parts that don’t scale well. Throw a bit of load to it – either bypassing the CDN or tailoring it to discover bottlenecks and deliberately hitting weak points to see where that actual fail point exists. You want to aim for breadth and depth.
Q: What about digital engagement – where’s it heading?
A: We’re finding that people are reviewing key aspects of their design at the moment and we would encourage anyone who is either already in the online space or looking to move more deeply into the online space to review application design. There a number of different ways to build in flexibility and scalability – having a microservices architecture, or using cloud-based, auto-scaling features, for example. Even if you can’t get that ready in time for this peak, next year’s peak will be more predictable because it will be a repeat run in this sort of climate. If things go back to normal by then, that’s great but I doubt they will. So, look at how your systems are able to handle additional load, at the optimisation of resources within your application, and work on those key aspects, starting now.
Monitor everything all the way through your stack to see where you can eke out microseconds and milliseconds of performance. Set a performance budget: “I want each page to load within ‘x’ time and I would like this journey to be completed within ‘y’ time”. Iterate fast and create continuous integration cycles that allow you to make small changes often and on a repeatable and continuous improvement journey.
Q: Any final thoughts?
A: In summary, I would say there are four things that come to mind. One is to know your application limits: understand where it will survive and where it will struggle, through the process of a sound testing methodology. Next is to leverage third-party expertise where applicable. Talk to peers, know who your vendors are and where they can help you. Then, remember that applications that scale and can adapt quickly are at lower risk of failing.
Finally, be prepared to succeed. If suddenly everybody wants what you have, can you deliver it to them?