Loading...
Learn how to nail Agoda's toughest behavioral question using the STAR format, with real system design examples and exact phrasing to impress your interviewer.
Here's the thing most candidates miss — when Agoda asks "Tell me about a time you had to re-architect a system that was failing under load," they're not just asking for a war story. They're stress-testing your engineering judgment, your ownership mentality, and your ability to communicate technical decisions to both engineers and stakeholders.
Agoda operates at massive scale — millions of hotel and flight bookings, real-time pricing engines, and flash sale traffic spikes. They need engineers who have been there, made hard calls under pressure, and can articulate the "why" behind architectural decisions. If you can't tell this story well, you're leaving a huge signal on the table.
Let's walk through exactly how to structure and deliver this answer.
Before you open your mouth, understand what signals they're listening for:
A strong answer shows all five. A weak answer usually covers maybe two.
STAR stands for Situation, Task, Action, Result. You've heard this. But for a technical behavioral question at a company like Agoda, there's a hidden fifth element: Reflection. What would you do differently? What did you learn? That's what separates a senior engineer answer from a junior one.
Let's break each section down with coaching notes.
Don't spend three minutes on context. Your interviewer wants to understand the scale and stakes fast. Practice this framing:
"We were running a flash sale notification system that sent personalized deal alerts to about 2 million users. During peak campaigns, we were seeing p99 latencies spike to 8 seconds and the service would start dropping messages entirely."
Notice what that does: it gives scale (2M users), a concrete symptom (p99 latency, dropped messages), and a business impact (campaigns failing). That's all you need.
A common trap here: candidates spend too long on the backstory and never get to the interesting part. If you catch yourself still explaining the Situation two minutes in, cut it short.
This is where candidates often undersell or oversell themselves. Be precise:
"I was the tech lead on the notifications team. I was responsible for diagnosing the bottleneck, proposing an architectural solution, and coordinating the migration with zero downtime — while the marketing team still needed to run campaigns."
The interviewer is checking: Were you a decision-maker, or just an executor? At Agoda, they want people who can lead under ambiguity. If you were junior at the time, that's fine — just be honest about your scope.
This section should be the longest and most detailed. Walk through your diagnosis, your decision-making process, and the technical changes you made. Don't just say "we moved to microservices" — that tells them nothing.
Here's how to structure the Action section:
Step 1: Diagnose before you prescribe.
"My first step was to get visibility. We added distributed tracing with Jaeger and within a few hours we could see that the bottleneck was our notification dispatch service — it was a single-threaded consumer reading from a Kafka topic and making synchronous HTTP calls to a third-party SMS gateway."
Step 2: Explain the root cause with technical depth.
"The core issue was that one slow downstream call could block the entire consumer. During flash sales, the SMS gateway would throttle us, and our queue depth would explode from thousands to millions of messages within minutes."
Step 3: Walk through your options and the tradeoff you made.
This is huge. Interviewers love hearing: "I considered X, Y, and Z. Here's why I chose Z."
"We had three options: scale up the consumer horizontally, switch to async fire-and-forget calls, or rebuild the dispatch layer with a proper worker pool and circuit breaker. Horizontal scaling would've helped short-term but not fixed the root cause — one slow gateway call still blocks a thread. Async fire-and-forget risked silent message loss, which marketing couldn't accept. So we went with option three."
Step 4: Show the technical implementation.
Here's where you can drop in a code-level example to prove you actually built this:
import asyncio
from circuitbreaker import circuit
from asyncio import Semaphore
MAX_CONCURRENT_DISPATCHES = 50
semaphore = Semaphore(MAX_CONCURRENT_DISPATCHES)
@circuit(failure_threshold=5, recovery_timeout=30)
async def send_sms(user_id: str, message: str) -> bool:
async with semaphore:
try:
response = await sms_gateway.post(
'/send',
json={'to'
See what this communicates? You understand concurrency control, circuit breakers, timeout handling, and observability. That's four senior-level signals in one code block.
Step 5: Describe the migration strategy.
"We did a shadow rollout — the new async dispatch service ran in parallel with the old one, reading from a shadow Kafka topic with duplicated messages. We monitored both systems for 48 hours before cutting over. Zero downtime, no campaign interruptions."
Here's a simplified version of the Kafka topic routing we used:
# Kafka consumer group configuration during shadow rollout
consumer_groups:
- group_id: notifications-legacy
topics:
- notifications.dispatch
partitions: 12
max_poll_records: 100
- group_id: notifications-v2-shadow
topics:
- notifications.dispatch.shadow # duplicated via stream processor
partitions: 48 # increased parallelism
max_poll_records: 500
processing_mode: async
circuit_breaker:
enabled: true
failure_threshold: 5
recovery_timeout_seconds: 30Showing infrastructure-as-code or configuration-level thinking signals that you think about operations, not just code.
Don't say "it got better." Say:
"After the cutover, p99 latency dropped from 8 seconds to under 400ms. Message throughput increased from 12,000 messages per minute to 85,000. During the next flash sale, the system handled 3x peak load without any manual intervention. The marketing team ran four consecutive campaigns without a single escalation to engineering."
Numbers. Before. After. Business impact. That's the formula.
"If I could do it again, I'd have invested in observability before the crisis. We flew blind for the first 48 hours because we had no distributed tracing. That's a lesson I took to every new system I've worked on since — you instrument first, optimize second."
This shows self-awareness and growth mindset — two things Agoda explicitly values in their engineering culture.
Here's some exact phrasing you can borrow and adapt:
Opening the story:
"I'd like to share an experience from my time at [Company], where we had a notification dispatch system that was failing under campaign load. Can I walk you through the full arc from diagnosis to resolution?"
Transitioning between STAR sections:
"So that's the situation — let me tell you what I was specifically responsible for..." "Once I understood the root cause, I had to make a call between three different approaches. Here's how I thought about the tradeoffs..."
Handling a curve-ball follow-up:
"That's a really good question — we actually considered that. The reason we didn't go that route was... [explain]. In hindsight, it might have been worth exploring further, but given our time constraints..."
Closing strong:
"The biggest thing I took away from this was [lesson]. It changed how I approach capacity planning / observability / stakeholder communication on every system I've worked on since."
| Follow-Up | What They're Really Checking | How to Handle It |
|---|---|---|
| "How did you convince leadership to prioritize this?" | Influence without authority | Talk about framing it as business risk, not a tech problem |
| "What would you have done differently?" | Self-awareness and growth | Have a genuine answer ready — no one does things perfectly |
| "How did you ensure no data loss during the migration?" | Operational rigor | Describe your rollback plan, shadow testing, and monitoring |
| "How did you decide on the concurrency limit of 50?" | Data-driven decision making | Talk about load testing results, downstream throttle limits |
| "What happened when the circuit breaker opened?" | Edge case thinking | Explain your fallback behavior and alerting strategy |
You've got a great story to tell. The goal now is to tell it clearly, confidently, and with the specificity that makes Agoda's interviewers lean forward and think: this is exactly the kind of engineer we need.