Launching Drops
A look at how Tech @SSENSE handles High Traffic Launches
Long before COVID-19, there were few moments in the life of a retail employee that evoked anxiety, like the thought of Black Friday shoppers swarming through the entryways of stores, or seeing customers lining up down the block for the release of a limited edition pair of sneakers. In comparison, software engineers in the world of ecommerce see their product pages, checkout experiences, and accompanying software tools that enable the website as representing that same doorway — but instead of calling it Black Friday Madness, developers call the event a “high traffic launch” or HTL.
For a technology platform like SSENSE which offers hundreds of brands; these events aren’t just important, they’re crucial to establishing SSENSE as the preeminent destination for product launches. Add to the fact that high traffic events are only growing larger and more frequent, and you begin to understand the velocity at which the engineering teams at SSENSE need to perform.
To understand more about what makes a successful high traffic launch event at SSENSE, I sat down with Principal Software Developer Agustin Sacco (AS), and Full-Stack Developer Jean-Philippe Lingrand (JPL) to talk about resilience, team dynamics, and what it’s like to be behind the wheel of these increasingly important events at SSENSE.
What’s a SSENSE HTL like? What do we consider a HTL and how often do they occur?
JPL: A SSENSE high traffic launch is a period in time where the company as a whole directs a significant influx of traffic towards platforms like our website, applications, our customer service teams, and our personal stylists. They’re generally punctuated by events like inventory running out, or time elapsing for the period in question. HTLs happen multiple times throughout the year, such as new product, brand, or category launches, specific inventory listings and product releases, or the start dates of seasonal markdowns.
AS: On the backend, a HTL is a moment that triggers several hundred thousand actions [or calls] to a network of interconnected services that operate our business [called microservices]. HTL’s average between 20–30 times the number of requests per second to these microservices in comparison to regular off-season traffic. A single click from a customer will create dozens if not hundreds of these actions which in turn, help to create a customer’s SSENSE online shopping experience; from displaying available sizing and inventory, to offering additional suggested items. So, while our customers consider it a product release or a launch — we see it as a test of how our code scales and stands up to pressure.
Take us through the HTL experience through the lens of an SSENSE customer
JPL: For the customer, a HTL is a high-pressure moment where they need to navigate from a product listing page all the way to a checkout confirmation page without a hitch. The pressure generally comes from the fact that they know a product’s inventory is scarce, time might be limited, and they’re waiting for their page to load. More often than not, this is what we mean by our customers having a seamless customer experience during a high traffic launch.
One of the major factors that drives a seamless customer experience is site resiliency — which is all about ensuring the structure and services our site offers to our customers won’t break down and that the site will not encounter any downtime. What that ultimately means, is that customers end up trusting SSENSE to deliver during a high-demand period — which in turn fosters loyalty and retention by establishing SSENSE as a destination of choice for future releases and launches.
AS: At SSENSE, we consider it an organizational principle to give each customer the same consistent experience including response times, add to bag, and checkout. It puts a significant strain on our inventory management system, but our commitment remains around creating customer experiences that can deliver consistency to the greatest number of people without having to rely on chance.
Another way to think about it is that while it might be a HTL for the company and the website — many customers are getting to know SSENSE during these types of events. So we need to ensure any new customer’s site experience can stand alone and stand up to SSENSE standards. The ultimate equation of any HTL turns into a balance of quantity and quality.
How does the technology team prepare for an HTL?
JPL: Long before the items ever make it to their product listing pages, our team of product managers and buyers work together to determine which events should be considered a HTL, and to what degree we classify them. So we actually have a roadmap designed around HTLs.
Leading up to the events, engineers have already flagged potential threats and opportunities across the site’s services [in this case, a service can be something like site/product personalization while you browse, previous order tracking, displaying the # of items in a shopping cart, etc] which might cause bottlenecks or load issues to our microservices and systems during a HTL shopping experience.
We then work with our product management team and senior management, to align on something called a “graceful degradation” which allows the site to pause certain services while delivering an optimal user experience that serves the largest number of customers.
What kind of impact does a HTL have on the website?
AS: For some engineers, it might mean waking up extra early to launch the newest set of sneakers to the site and wait… but generally across the rest of the team we run on high alert. At this point, we have planned and designed any site degradation in advance, but we are constantly monitoring and testing the system performance to accommodate larger amounts of traffic.
JPL: We’ve designed each launch in advance, to have as minimal of an impact on the customer as possible. And while that can sometimes mean they don’t have access to a feature like a visible shopping bag across every page of the site, or that the site might not be recommending as many products as it would during a regular timeframe — the overall experience remains something we can be proud to offer our customers.
On the backend of things, and in preparation for any HTL we also implement circuit breakers which are put in place to protect the site, helping us avoid any downtime and adding additional layers to site security. Circuit breakers take the load off of any features, services, or legacy systems that might buckle under the pressure of a HTL. Moving forward, any new architecture a team comes up with needs to be designed to support our HTLs. Teams are constantly designing for larger and larger scale, making it really exciting when we launch into a HTL with new architectures or features.
AS: In an effort to both standardize and automate things, the team is designing machine learning controls and continuous monitoring systems which will help automate some of the ways the site reacts during a high traffic event. These systems will help eliminate any human error [or uncertainty/hesitancy] as certain launches across our platforms have had half-lives lasting mere minutes. Every millisecond counts when it comes to someone having a positive experience.
Are there a particular moment during an HTL you worked on, that stands out to you?
AS: No matter how much you plan; sometimes you can’t predict how big things will be, and launches take an unexpected turn. It’s a bit masochistic of me to say this, but even when things went south we ultimately came out stronger as we conducted analyses and gathered incident reports that helped us plan the next HTL. It’s like the scientific method of proving or disproving a hypothesis, but with systems designed to scale like ours, we only get stronger with each event.
JPL: Agreed. I think it’s also important to remember that HTLs can occur across a variety of inception points. Sometimes it’s a brand tweet that directs traffic to the site, other times can be when personal stylists let their tastemaking clients know about a new drop. I think all HTLs are much more prepared than we might ever let on, but it all boils down to being a testament to how we deliver on our customer promise and how we deliver the site experience.
How is the SSENSE understanding of HTL’s evolving and what would be your advice for engineers preparing for their next HTL?
AS: It’s important to actually call out that every HTL is in fact completely different from its predecessor because our systems are extremely distributed and our microservices are event-based. We’re constantly undergoing churn or migrating systems, there might even be times where we’re in limbo between two systems. That’s what makes every HTL at SSENSE different: how the context in which it exists is never static. So on the front end, nothing should ever feel too new for the customer — but for a developer, we’re there to make continuous improvements and drive impact.
For SSENSE, our monitoring and telemetry are always evolving and becoming more detailed to allow us to create efficiency when there is opportunity. The only way to notice this inefficiency is by having top of the line monitoring and alerting on our systems.
Additionally, as we decrease the time to resolution of triggered alerts or monitors, that means removing human intervention at every level of a HTL. So we are designing automated systems that are smart enough to degrade experiences on the fly when certain systems are undergoing pressure as a result of high traffic.
JPL: HTLs at SSENSE are about upholding the commitment you make to customers and your team, around what you’re prepared to do to uphold 100% site uptime and customer experiences. It’s a highly engaging, high impact moment — and it’s constantly changing as our systems evolve. As much as you can, plan for the unexpected.
As high traffic launches continue to grow, and their ability to foster customer loyalty becomes increasingly contingent on delivering a seamless customer experience — engineering departments and their architects will continue to bear a heavy load. Platforms like SSENSE, who plan for and are able to distinguish themselves at building faster, more resilient, reliable, and personal experience — should ultimately be the ones delivering the goods.
For more information around resilience and downtime see the SSENSE-TECH blog posts on Putting The Breaks on Downtime, and Improving the Resilience of your Software: a Practical Approach.
Want to work with us on our next High Traffic Launch? Click here to see the open positions at SSENSE!
Editorial reviews by Deanna Chow, Liela Touré, and Mario Bittencourt.
