Re-Architecting Systems Under Load: Ace Agoda's Toughest Behavioral Question

Re-Architecting Systems Under Load: Ace Agoda's Toughest Behavioral Question | TheMentor

What Agoda Is Really Testing Here#

When an Agoda interviewer 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.

Here's what the interviewer is actually checking:

Can you diagnose a system problem under pressure, not just react to it?
Do you understand the why behind architectural decisions, not just the what?
Did you take ownership, or did you just follow someone else's lead?
Can you quantify impact? (Agoda runs one of Southeast Asia's highest-traffic travel platforms — they live and die by numbers.)

Agoda is a data-driven engineering culture. Vague answers like "we improved performance significantly" will not land. Numbers, metrics, and trade-offs are your best friends in this room.

The STAR Framework — But Done Right#

Most candidates know STAR (Situation, Task, Action, Result). But most candidates also blow it by spending 80% of their time on Situation and Task and rushing through the Actions — which is exactly backwards. The interviewer cares most about what you did and how you thought.

Here's the ratio you should aim for:

STAR Component	Time to Spend	What to Cover
Situation	~15%	Context, scale, what broke and when
Task	~10%	Your specific ownership and constraints
Action	~60%	Diagnosis, decision-making, trade-offs, implementation
Result	~15%	Metrics, lessons, what you'd do differently

Let's walk through each one with coaching notes.

Situation — Set the Scene Fast#

You have about 60 seconds here. Don't over-explain the company backstory. What you need to convey:

The system and its purpose
The scale (requests per second, users, data volume)
When and how it started breaking

Example opening you can adapt:

"This was at my previous company — we were running a hotel availability search service that handled roughly 8,000 requests per second during peak travel season. About 18 months into production, we started seeing P99 latency spike from 200ms to over 4 seconds during flash sale events, and our error rate climbed to around 12%."

Notice what's in there: a real system, real numbers, a real trigger. The interviewer is already leaning in.

Common trap: Starting with "So our monolith was really old and..." — this signals you're going to blame legacy tech rather than show engineering judgment.

Task — Establish Your Ownership#

Be crystal clear about your personal role. Agoda interviewers will probe this. They want to know if you were the architect, a contributor, or just the person who got lucky being in the room.

Good:

"I was the tech lead for the search platform team. My manager gave me the mandate to diagnose and fix it within two sprints, with a hard constraint that we couldn't take the service offline."

Weak:

"Our team worked together to investigate and fix the issue."

The word "our" is a yellow flag unless you immediately follow up with "my specific responsibility was..."

Action — This Is Where You Win or Lose#

This is the heart of your answer. Let's break it into the phases a strong candidate covers.

Phase 1: Diagnose Before You Prescribe#

Here's the thing most people miss — interviewers love candidates who diagnose systematically before jumping to solutions. If you open with "so I decided to move to microservices," you've already lost points.

Talk about how you found the root cause. Was it:

Database connection pool exhaustion?
A hot partition in your cache?
N+1 query patterns surfacing under load?
A synchronous dependency becoming a bottleneck?

Example diagnosis narrative:

"First, I pulled our APM traces from Datadog and found that 70% of our latency was happening inside a single synchronous call to our inventory service. The inventory service was doing a full table scan on a 200-million-row MySQL table for every search request because someone had dropped an index during a migration six months earlier. Under low load, it was fine. Under peak load, the connection pool saturated and requests started queuing."

That's a specific, credible diagnosis. It shows you know your tools and your data.

Phase 2: Explain the Trade-offs You Considered#

Agoda is big on engineering trade-offs. Don't just say what you chose — say what you didn't choose and why.

Sample code showing the problematic pattern you identified:

python

# BEFORE: Synchronous blocking call on every search request
def search_hotels(location, check_in, check_out):
    hotels = db.query("""
        SELECT h.*, inv.available_rooms
        FROM hotels h
        JOIN inventory inv ON h.id = inv.hotel_id
        WHERE h.city = %s
        AND inv.date BETWEEN %s AND %s
        -- Missing index on (city, date) — full table scan!
    """, (location, check_in, check_out))
    
    return [format_hotel(h) for h in hotels]
    # P99 latency: 4200ms under load
    # Blocks a thread for the full duration

Then walk through your options:

"I had three options. Option one was to just re-add the index — quick fix, but it didn't solve the architectural problem of every search hitting the database directly. Option two was to introduce a Redis caching layer for availability data with a short TTL. Option three was to pre-compute availability into a read-optimized search index using an async pipeline. Option one was a band-aid. I recommended option three with option two as an interim fix we could ship immediately."

This shows strategic thinking, not just coding ability.

Phase 3: Walk Through the Implementation#

Show the interviewer you actually built this, not just designed it on a whiteboard.

python

# AFTER: Async pre-computation pipeline + read-optimized cache
import asyncio
from redis import Redis
from kafka import KafkaConsumer
 
redis_client = Redis(host='cache-cluster', decode_responses=True)
 
# Consumer: listens for inventory updates and rebuilds the search cache
async def inventory_update_consumer():
    consumer = KafkaConsumer('inventory.updates', group_id='search-cache-builder')
    
    for message in consumer:
        hotel_id = message.value['hotel_id']
        await rebuild_availability_cache(hotel_id)
 
async def rebuild_availability_cache

Point out the deliberate design decision: "Notice we accepted 5 minutes of potential staleness on availability data in search results — the actual booking flow still hit the source of truth. That was a conscious trade-off between consistency and performance that I got sign-off from product on."

That sentence will make an Agoda interviewer nod. They deal with exactly this trade-off every day.

Result — Quantify Everything#

Don't say "performance improved dramatically." Say:

"After shipping the interim Redis cache, our P99 latency dropped from 4,200ms to 180ms within 24 hours. Error rate went from 12% to under 0.3%. Three weeks later when we shipped the full Kafka-based pre-computation pipeline, we handled a flash sale with 3x our previous peak load without any degradation. We also reduced our MySQL read replica load by 78%, which let us defer a $40K/year database scaling cost."

Numbers. Business impact. Compound wins. That's a Result section that gets you to the next round.

Where Candidates Get Stuck#

The blame spiral: Spending too long explaining how bad the previous architecture was. Interviewers hear this as "I talk badly about past teams." Move to diagnosis and solutions quickly.
The team credit dodge: Saying "we" for every action. Own your contributions specifically.
Skipping the trade-offs: Jumping straight to "so I used Redis" without explaining what you considered and rejected. This is a huge miss at Agoda — they want to see your decision-making process.
No numbers in the result: "It got much faster" is not a result. If you genuinely don't remember the exact figures, say "approximately" — but have something.
Over-engineering the story: Picking a story where you rebuilt everything from scratch in a month. It sounds unrealistic. Pick a story that shows surgical judgment.

How to Talk Through This in an Interview#

Here's example dialogue you can adapt:

Interviewer: "Tell me about a time you had to re-architect a system that was failing under load."

You: "Great question — I have a strong example from my time at [Company]. Let me set the scene quickly. We were running a hotel search service at about 8,000 RPS. During a major flash sale, our P99 latency jumped from 200ms to over 4 seconds and error rates hit 12%. I was the tech lead tasked with diagnosing and fixing it without taking the service down.

The first thing I did was pull our distributed traces — I wanted data before opinions. What I found was that 70% of the latency was concentrated in a single synchronous DB call that was doing a full table scan due to a dropped index. But fixing the index alone wouldn't solve the architectural brittleness, so I proposed a two-phase approach..."

Then continue into the trade-offs and implementation as we covered above.

If the interviewer interrupts: "Why did you choose Kafka over a simpler polling approach?" — this is a gift. They're engaging. Answer it directly: "Polling would have created thundering herd problems at scale and added unnecessary DB load. Kafka let us decouple the write side from the cache-building side cleanly, and we already had it in our infrastructure."

Follow-Up Questions to Prepare For#

Agoda interviewers are thorough. Expect these:

"What would you do differently now?" — Always have a genuine answer. Shows self-awareness.
"How did you handle the data consistency problem during the migration?" — Talk about your rollout strategy, feature flags, and validation.
"How did you get stakeholder buy-in for a two-sprint delay?" — Shows you understand the business side.
"What monitoring did you put in place to catch this earlier?" — Talk about alerting on P95/P99, connection pool utilization, and slow query logs.
"What was the biggest risk in your approach?" — Own a real risk and explain how you mitigated it.

Red Flags to Avoid#

Saying "I convinced the team to rewrite everything in Go" without explaining why
Using buzzwords ("we went serverless") without technical depth
Being unable to explain a single component of your architecture when probed
Giving a story where everything went perfectly — real engineering has friction
Not being able to say what you specifically contributed vs. the team

Key Takeaways#

Spend 60% of your answer on Actions — that's where interviewers evaluate your engineering judgment
Diagnose before prescribing — show you used data, not instinct
Name your trade-offs explicitly — "I chose X over Y because..." is what strong candidates do
Quantify your result — Agoda is metrics-driven; numbers are non-negotiable
Own your contribution — say "I" when you mean "I," and "we" only when it's genuinely collaborative
Prepare for follow-ups — your story is the opener, the follow-ups are the real interview
Accept real trade-offs on the record — admitting you accepted eventual consistency or a 5-minute staleness window shows you understand real-world engineering, not just textbook solutions

You've got this. The candidate who wins this question isn't the one with the most impressive system — it's the one who can explain their thinking clearly, own their decisions, and back everything up with data.