Spring Boot Interview Question — Real-Time Seat Map Updates

Not Every Problem Needs a Walkie-Talkie. Sometimes a Radio Is Fine

Scenario

Your team owns a Spring Boot application that powers a live event booking platform.

When users open the event page, they see a seat map:

A1 AVAILABLE
A2 HELD
A3 BOOKED

As seats change state, all viewers should see updates immediately.

The current implementation uses polling:

GET /events/{eventId}/seat-map

every 5 seconds.

Incident

A major concert goes on sale. Within minutes:

50,000 concurrent viewers
1,000 seat updates/sec

Grafana shows:

Database CPU: 95%
API Requests/sec: 120,000
Average Response Time: 8s

Users complain:

“The seat map is lagging.”

“I clicked an available seat but booking failed.”

Question 1

What is causing the database and API load? Why does polling become inefficient at this scale?

50,000 users
↓
poll every 5s
↓
10,000 requests/sec
↓
mostly identical responses
↓
database overloaded

Most requests ask:

Has anything changed?

and receive:

No

Additionally, users still see stale data because updates are only visible on the next poll cycle. A seat booked immediately after a poll may appear available for several more seconds, leading to booking conflicts and poor user experience.

---

📢 Get actionable Java and Spring Boot insights every week, including practical code tips and real-world, use-case-based interview questions, to help you level up your backend skills—join 7600+ subscribers for hand-crafted, no-fluff content.

First 100 paid subscribers will get the annual membership at $50/year forever that is ~ $4/mo ( 91 already converted to paid, 9 remaining)

So far we have covered 67 real world based interview questions and will add up to 100 by end of this year.

Testimonials

---

---

Question 2

You peer developer proposes reducing the polling interval:

5 seconds → 1 second

Will this solve the problem?

Answer

No. It improves freshness, but it makes the scalability problem significantly worse.

With 50,000 concurrent users:

5-second polling
= 10,000 requests/sec

Changing to:

1-second polling

becomes:

50,000 requests/sec

That's a 5x increase in API traffic, database reads, network bandwidth, and infrastructure costs.

The core problem remains:

50,000 users
↓
50,000 requests every second
↓
Most responses say:
"Nothing changed"

We’re still generating work based on the number of viewers rather than the number of seat updates.

For example:

50,000 viewers
1,000 seat updates/sec

The system processes:

50,000 requests/sec

to deliver only:

1,000 meaningful changes/sec

which is highly inefficient.

The real solution seems to switch from a pull model (polling) to a push model where updates are sent only when seat state actually changes. This makes system load proportional to seat updates rather than viewer count.