Lessons from Supporting Hundreds of Peak Traffic Events with Praveen Thakur

Episode transcript:

Jose

Hello and welcome to the smooth scaling podcast where we are speaking with industry experts to uncover how to design, build and run scalable and resilient systems. I'm your host, Jose Quaresma, and today I'm joined by Praveen Thakur, who's the head of technical engagement in APAC here at Queue-it. Praveen has spent the last four years supporting Queue-it customers in preparing for, monitoring and assessing the success of their biggest days. I really enjoyed our chat. And the highlights for me were the insights that he shared into how different companies approach peak traffic, what it looks like inside a mission control room, and the importance of defining clear success criteria. Enjoy. 

Welcome, Praveen.

 

Praveen

Thank you very much, Jose.

 

Jose

It's great to have you here. I guess we've been working together for two years now, and it's a pleasure to have you on the podcast.

 

Praveen

Thank you very much. It's my pleasure to be here.

 

Jose

Praveen, I think we should get right into it. So your Queue-it's head of technical engagement for the APAC region. And can you start by sharing a little bit what technical engagement in Queue-it really is and what’s a day in the life of a technical engagement manager?

 

Praveen

So technical engagement at Queue-it is, in my opinion, a very critical role. It spans from pre-sale cycle till the whole journey of the customer. So normally we’re referred to as TEM—which is nothing but a solution architect or solution engineer working in technical engagement. 

And our journey starts from the very first interaction with any prospect. That's where we try to understand what they are looking for, how we can help them transition into onboarding once they become our customers. Help them in go-lives, monitoring their events. And then that journey still continues with support, training, and so and so on, till the time they are our customers, right? So that's what we do as TEM.

Now, the second part of your question was “how does the life of a TEM look”. So looking at this, I can easily say, no two days are the same for any TEM in Queue-it. Because it's not just one stream of work, we work in pre-sales onboarding.

So one day you might be talking to a banking customer in a pre-sales capacity and in the next hour, you might be monitoring a very high-profile event on a ticketing industry, and next day could be totally different. So no two days are the same. it's very hard to describe but how I describe it to people in my team outside being a TEM you need to be flexible, and that flexibility doesn't mean from your timing perspective or anything. It spans across technology, breadth is very important. When you are talking to an ecommerce company, you need to have understanding of how  e-commerce systems work, what are the things in e-commerce ecosystem. 

When you're talking to a banking customer, for them security is most important. How secure is their data? Are we capturing any data?

So yeah that that kind of flexibility is needed in the role and you just get used to it. I'll say even within Queue-it if I look at the last four years I've been, there’s been a transition. When I joined there were different problems to solve. When I talk to customers these days, those problems have shifted from one end to another end.

 

Jose

And maybe we'll get to a bit of those problems a bit later in the podcast. 

But I really like the kind of the versatility and the flexibility that you mentioned there. When I think about it as well, I think part of it is that, yes, our solution architects, solution engineers, they do need to understand our product. But also often, that's not enough. You need to go and also work with the customers to understand their infrastructure and their technology stack and that that can be very wide. 

Now, backtracking slightly, how did you get to head of technical engagement for APAC at Queue-it can you tell us a little bit about your journey?

 

Praveen

Almost 18 years back I started as a software developer passing out of university. Most of the time I spent was in service or consulting world or a product company working as a software engineer, then leading a team, and so and so on. 

At one stage, I was like, “OK, now it's been enough of consulting, enough of working on various products. Let's see the world on the other side.” And before my role at Queue-it, I was working in Tourism Australia. So Tourism Australia is a tourism body for Australia how we can bring in more tourists to Australia.

But after I was there for two years, I realized there are still a lot of problems because we used to be dependent upon many vendors and so on. And I can see those challenges. 

And when I was then, this role came up in Queue-it to start the APAC office in Sydney which sounded very interesting but when I started speaking to people, I was very impressed with how much we care about our customers.

I’m not trying to brag on behalf of Queue-it, but I was genuinely surprised by how well we take care of our customers. And it's not just me—I’ve heard this feedback from various customers over the last four years. It’s about what we say and how we support, even after the sales cycle. I’ve seen the other side. When I was at Tourism Australia during the sales cycle, there's a lot of attention. But once you become a customer, there can be huge delays and so on.

So that was the journey. The role was new, and I could easily see the pain points from the other side—and what I could help solve by being at Queue-it.

 

Jose

What does the process look like? Let's say I’m a retail company getting ready for the holiday season and expecting some major traffic, probably with some peaks. I'm coming to you for help. Can you share, at a high level, what that process looks like? Are there specific questions you would ask me? I know it's maybe hard to summarize, but can you give it a try?

 

Praveen

So normally, that journey starts with some of the sales conversations, or I’ll join in a pre-sales capacity as a technical architect to understand their ecosystem. But it's not just about the tech. The first and foremost thing for us is to understand why they need Queue-it. What’s their business model?

Are they offering heavy discounts—like many retailers—or are they selling something with limited supply and high demand? Those are very different scenarios. We first qualify that—okay, now we know we can definitely solve this problem.

Then we go deeper into technical details: What’s the right way to integrate them? Are they using a CDN, or some other technologies? What are the options available on our side? The business problem also guides the technical decisions.

We can’t paint everything with the same brush. For example, we always want to make our solution secure, ideally through server-side integration. But sometimes we come across customers who have different needs.

There’s a big retailer in Australia, for instance. They use us every Black Friday, but still rely on JavaScript integration. For them, the success factor isn’t necessarily fairness—it’s about keeping their system up and running. What they’re selling isn’t limited in supply. If you don’t get it in the morning, you can still get it in the afternoon.

On the other hand, for customers selling, let’s say, PS5s, fairness really matters. We need to close all security holes and loopholes in the system.

So that’s how it goes. Integration on Queue-it’s side is straightforward—I’d say it's not that complex once you understand it.

Then the next hurdle comes once we go live—the big day arrives. That’s the most important moment for the customer. We have to ensure they’re operating at a level their system can handle.

It’s important for us to identify any weak points—third-party services, for example. Many times, customers will say, “We have a payment service,” but we can’t really test it properly. That’s a tricky situation. Or they might rely on services that aren’t available in the testing environment, so how do we anticipate how those services will behave in production?

That’s when we define creative ways to assess risk. We might say, “Okay, in that case, let’s look at the rate you’ve historically sustained.” If you can’t load test it, let’s check analytics from the past 12 months. When did you see the highest traffic while your system remained stable? Start from there and adjust forward if needed.

But in some cases, it's really tricky. Success criteria can be very different from customer to customer.

I’ve also seen customers say, “For us, success means not putting people in the waiting room at all.” That’s a tough one—because they want to maximize throughput without users even seeing the waiting room. That’s what we call, "max-out flow."

Those are critical moments. We take the customer through that journey, help them understand the trade-offs.

At the end of the day, we help with monitoring. We have a lot of tools to track what's happening—whether the system is performing well or not. We use those real-time indicators to help smooth the sale.

So yeah, that’s what we do. That’s more or less what the journey looks like. And of course, there are many nitty-gritty details that vary from one customer to another.

 

Jose

Do you see any patterns when working across the APAC region? Anything that stands out—maybe certain regions focusing more on specific use cases or success criteria than others?

 

Praveen

I can see that, and you’re right. APAC sounds small, but we’re talking about at least four to five major subregions—and even within Australia, we have four time zones. So you’re dealing with different time zones, different cultures, and a lot of variation in how things are approached.

When I talk to customers in Australia and New Zealand, that’s a very different story. For them, what's important is clear. They’re generally more willing to accept how the product works and try to work around that.

If we’re talking to a customer in Southeast Asia, they often have their own understanding of how a virtual waiting room should work. Taking them through that journey—it's not a challenge per se, but it’s definitely a process. So sometimes what you need to do is say, “Okay, let’s go step by step.”

In Southeast Asia, there’s a lot of bot activity happening right now. And in their mindset—or culturally—the expectation is: “If we have Queue-it in front of our system, there shouldn’t be any bots.” But the reality is, bot activity is a moving target. We implement one countermeasure, they come up with something else. Then we adapt, and they adapt again. So that aspect is very different.

Just recently, I was on a call with a large ticketing provider here in Australia. They were running four or five major sales on the same day. There were a lot of people on the call, and we identified some suspicious activity. The customer said, “Okay, we see it. Let’s make a decision. What needs to be done?” And with some of the tools available in our product, we were able to block those suspicious users—and the customer was very happy with that.

But if I had to make that kind of decision with a Southeast Asian customer, it would be a challenge. They wouldn’t take that decision on the spot.

 

Jose

I think we touched a bit on the different use cases—we didn’t name them, but we started with the example of me being a retail company. Maybe we can follow up on that example a little more. In that case, I’m preparing for a peak traffic event, right? Something scheduled—maybe it’s a Black Friday sale at midnight—so I know exactly when I need to be ready.

You also mentioned some other customers who are more focused on not necessarily showing the waiting room. And I think that connects well with our 24/7 peak protection use case. So it’s not just about preparing for a specific event—you can also use Queue-it as a kind of insurance policy. If a sudden spike in traffic happens, the waiting room kicks in automatically.

Is that how you see it, especially with customers who prefer not to show the waiting room? Because, in some cases, the waiting room is actually a benefit—it can be a really positive part of the user experience. But for those customers focused on avoiding it, do you see that more as a fit for the 24/7 peak protection use case?

 

Praveen

Not necessarily. I’ve seen it in both cases—even with scheduled waiting rooms. I wouldn’t call it a competition, but there are often two teams within a customer’s organization.

One team is focused on sales KPIs—they care about how quickly they can sell. They want to project that they have enough capacity, regardless of traffic volume.

On the other hand, the IT or operations team is responsible for keeping the infrastructure stable. Their KPI is system uptime. So they view Queue-it more as a safety net: “If something goes wrong, we still want to be up and running.”

So there’s this dynamic—business teams pushing for maximum throughput, and IT teams wanting a safeguard in place.

I haven’t seen the “don’t show the waiting room” mindset as much with retailers. It comes up more often with government organizations, where the perception among citizens really matters. They want to ensure all services are available 24/7, and avoid any message that might suggest limited access.

 

Jose

You mentioned the balance between the infrastructure and the business side. I think there’s a really interesting use case that can seem counterintuitive: even if your infrastructure can handle a lot of traffic, you might actually want to restrict it depending on your supply.

So, if you're only selling a limited amount of product but a lot of people want it, it can actually be an advantage to slow down the flow. Especially in cases like ticketing—if it's reserved seating, and too many people try at once for a small pool of inventory, you get a lot of clashes.

Even if the system can technically handle the load, it might still make sense to reduce the flow so you can have better control over the purchase process. That was something that really clicked for me when we discussed it a while ago.

 

Praveen

You’re right. I was actually having a similar conversation a few weeks back with a prospect—still in the pre-sales stage. They had a very different idea when they first described their problem.

They were planning a campaign where a limited number of coupons would be available for a few customers. The number wasn’t very high, but their system could handle a large volume of users. Still, they were asking, “Can we do something where we release users from the waiting room one by one?”

That’s when I started asking the right questions: “How many coupons do you have? What’s the inventory?” The conversation wasn’t about system capacity—it was really about how to create the right experience for users. You want users to see that there's demand, and that if they wait, they’ll get something.

Because the worst-case scenario is letting a thousand users in when you only have 800 items available—you end up with disappointed customers and a poor experience.

 

Jose

Let’s go back to my retail company, and we’re getting closer to the holiday season. It’s the big day, and I’ll be setting up a mission control room to monitor everything closely.

Can you take us inside that kind of mission control room? What does it look like? Who’s in the room? What are people looking at? How are they communicating? I’d love to get some tips for my retail company.

 

Praveen

That’s a really good question. I’ve been part of those war rooms or monitoring rooms with various customers.

Most of the time, I’m interacting with the operational teams responsible for keeping the infrastructure running. I wouldn’t say those rooms are always tense—it really depends on the situation. I’ve seen war rooms with just two or three people, and others with over 40, depending on the customer’s size.

There’s also been a shift over the last four years. Back then, the conversations were mainly about traffic volume, system performance, CPU usage—“Is it at 80%?” or “What’s our memory doing?” “Do we need to adjust max outflow?”

Now, especially during high-profile events, the focus has changed. These days, conversations are more like: “Do we see any suspicious users?” “Can we take action on this specific traffic?”

In some war rooms, business teams are present too. For example, with a ticketing company, success isn’t just about speed—it’s about whether they’re selling at the expected pace. That matters because if they sell out, say, 30,000 tickets quickly, the artist might announce a second show. So business outcomes drive some of that real-time decision-making.

In retail, the business side might be monitoring social media—someone tweets about an error or bad experience. Then the conversation becomes, “How do we handle that?”

That’s why we focus heavily on preparation before those big events. There’s no point showing up to a war room if we haven’t done the groundwork. Because once Queue-it is in front of their website, even if the issue isn’t caused by us, the first question is often, “Is this a Queue-it problem?”

So we do thorough checks beforehand to ensure everything is properly configured. And during the event, if we detect suspicious bot activity, we help customers understand what’s happening and what actions they can take.

If there’s something being reported on social media, we look into system logs to see: Is this a real issue? Is someone trying to game the system? Or is it a legitimate user issue?

It’s also important for business teams to be able to communicate the right message to their end users. So the balance between technical KPIs and business success criteria is key.

I remember a unique case—not retail or ticketing—but an island in Western Australia. We work with the organization that manages bookings there. Their system works fine, they’ve been a customer for three or four years. But for them, if even one person makes two bookings in a single window and tweets about it, it can escalate all the way to a government minister.

So it becomes very important for us to show, with data, that it wasn’t cheating—maybe it was just luck. Maybe that person had two devices and both got good queue positions.

So yeah, the atmosphere and the kind of work we do in those war rooms is as diverse as our role at Queue-it. The key is adapting—and most importantly, understanding the business and what they’re trying to achieve from the event.

 

Jose

Totally, totally aligned there. That makes sense.

So, my retail company—we went through the mission control room, we went through the event. It's now a few days later, and we’re getting to the end of the example. Usually, we have a post-event evaluation or assessment, right?

So maybe two questions: in your experience, how do we usually help our customers understand what happened? And also, can we talk a bit about where we commonly see mistakes or challenges?

 

Praveen

Yeah, the most common mistake—or theme—that comes out of those debrief sessions, or when we analyze post-event data, is that customers tend to plan based on the “happy path,” the ideal user journey.

But when end users try to access a sale, they’ll take all kinds of paths—left, right, anything they can. And that’s where those original assumptions can fail.

So a big part of what we do is help customers protect against those unexpected user journeys. That’s often one of the key learnings in those sessions.

 

Jose

That's a good point. That definitely stands out to me too—from the early discovery phase, when you start mapping out the user journey.

One thing is the happy path, but the real question is: are you covering the complete user journey? For example, if you want to protect a certain page, are you protecting all entry points to it? Or did you miss one—and then see the impact on event day?

That’s not easy, but it’s a critical conversation to have up front.

Another general thing we focus on a lot is making sure everything is integrated according to best practices. You mentioned checklists—that's such an important part. We can do a lot of prep work, but all it takes is one slightly misconfigured rule to create a loophole.

So there’s quite a bit of pressure to make sure all the i’s are dotted and the t’s are crossed before the big event.

You also touched on bots earlier. I think you said—correct me if I’m wrong—that you’re hearing more and more about this from customers. That it’s becoming part of the regular conversation, like, “Hey, this doesn’t look right.”

You’ve been at Queue-it for four years now—have you seen the bot landscape change during that time? What’s that evolution been like?

 

Praveen

I wouldn't say it's a change in the landscape, exactly—but more in the intensity. At the end of the day, these bots or bad actors have a simple goal: if it’s a limited supply sale, they want to buy the product and resell it on eBay or elsewhere at a higher price.

I’ve also seen cases where the bad actors aren’t even interested in buying anything. They just want to delay the process—disrupt the sale itself.

The shift I’ve seen over the last four years is in how often and how aggressively this happens. Four years ago, bot activity would show up in just a few events here and there. Now, especially for limited supply sales—like ticketing—it’s almost guaranteed that there will be some bot activity.

I don’t know if it’s just because the world is becoming more digital, or because there’s more noise and complexity in the digital space. But you see it across industries. For example, the kinds of attacks the banking sector faces today—that’s on a completely different level.

 

Jose

Yeah, I can see that. Like you described, it really feels like a constant evolution. The tools and techniques the attackers use are getting more advanced—and at the same time, our defenses are evolving too.

As you said earlier, it’s a bit of a cat-and-mouse game, and that’s going to continue.

But thinking about my retail company again—I’d like to improve my setup against bots for the next event. Do you have any recommendations I should consider?

 

Praveen

There’s no bulletproof solution, to be honest. But looking at success stories from customers we’ve worked with, one of the best strategies is knowing who your customers are.

If you can identify your users, you can create a setup where access is limited to known or verified customers. Even if bots show up, they'll get blocked at some point if they can’t prove their identity. So that North Star is always going to be identity. If we can accurately identify users, that’s the most effective path. But of course, that’s easier said than done.

As a retailer, your goal is to expand your customer base—you don’t want to restrict access only to people you already know. So the challenge becomes: how do you use that idea of “known customers” to your advantage?

One way is to limit access to high-demand products to verified or pre-registered users. But don’t think of it as restricting access—see it as an opportunity. You’re giving people a reason to become your customer. So it’s not about shutting people out; it’s about growing in a controlled way.

 

Jose

Sounds interesting—and useful! My retail company will definitely work with you on improving that setup.

Very good. I think we’re getting to the end of the example. No more fictional retail company.

We’d like to wrap up with a few rapid-fire questions. Don’t think too hard—keep it short if you can, but if you want to go long, that’s okay too.

First question: To you, scalability is...?

 

Praveen

To me, scalability goes beyond systems or infrastructure. It’s more about business outcomes and success—how you want to scale as a business. That could mean scaling your processes, your people—systems are just one part of it.

 

Jose

Second question: Is there a resource—a book, podcast, or thought leader—you’d recommend to the audience?

 

Praveen

Yes, there are many, but one that helped me recently is the book Extreme Ownership. Especially in the context I work in—dealing with customers and different teams—I’d definitely recommend it to anyone in a customer-facing role.

 

Jose

I'm happy to hear that—that’s a book I also enjoyed quite a lot.

So, third question: is there a particular technology you're really excited about for the future? And bonus points if it's not AI.

 

Praveen

Well, I have to say, the first thing that comes to mind is AI. But if I put it differently—maybe I’m twisting your question a bit—I’m excited about it, though not necessarily in an optimistic way.

I’m more curious about what it’s going to do over the next two to three years. Right now, it’s a buzzword—everyone wants to use AI for everything. But I think we need to wait and watch. So yes, I’m definitely watching it closely.

 

Jose

Great. Now, a double question to wrap things up—both about advice.

First: if you could give one piece of professional advice to your younger self, or to someone just starting in our field, what would it be?

 

Praveen

I’d say: always try to align what you’re doing with the business outcome.

 

Jose

And the final question—also about advice. If you could give one piece of advice to a company preparing for peak traffic—and it can’t be “use Queue-it”—what would that be?

 

Praveen

Define your success criteria—what you want to achieve from the event.

Whether you use Queue-it or any other technology, that comes second. First, be clear about what success looks like for you on that big day. Once that’s defined, the right solutions can follow.

 

Jose

I think that’s a great way to wrap it up. Thank you so much, Praveen, for joining us today. It was a pleasure to chat with you.

 

Praveen

It was my pleasure to be here. Thank you.

 

Jose

And that’s it for this episode of the Smooth Scaling podcast. Thank you so much for listening!

If you enjoyed it, consider subscribing and maybe share it with a friend or colleague. If you’d like to share any thoughts or comments, send them to smoothscaling@queue-it.com.

This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner. I’m your host, Jose Quaresma. Until next time—keep it smooth, keep it scalable.

 

[This transcript was generated using AI and may contain errors.]