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

Learn how to nail Agoda's system re-architecture behavioral question using the STAR format, with real examples and exact phrasing to impress your interviewer.

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:

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:

1. The system and its purpose
2. The scale (requests per second, users, data volume)
3. 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:

# 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.

# 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:

1. "What would you do differently now?" — Always have a genuine answer. Shows self-awareness.
2. "How did you handle the data consistency problem during the migration?" — Talk about your rollout strategy, feature flags, and validation.
3. "How did you get stakeholder buy-in for a two-sprint delay?" — Shows you understand the business side.
4. "What monitoring did you put in place to catch this earlier?" — Talk about alerting on P95/P99, connection pool utilization, and slow query logs.
5. "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.