Recently I interviewed a Senior Engineer.
Strong candidate.
Kafka? ✅
Redis? ✅
Microservices? ✅
Distributed systems? ✅
Then I asked:
"You're building the inventory service for a flash sale.
Only 1 item left in stock."
Two users hit “Buy Now” at the exact same millisecond.
Both requests pass the “is available?” check.
Both create an order.
Both deduct stock.
Now you’ve sold 2 items when only 1 existed.
How do you guarantee you never oversell — even with concurrent requests, client retries, and partial failures?
"Just use a database transaction."
Doesn’t fully solve it if both requests read `stock = 1` before either writes, or if the response is lost and the client retries.
"Check stock before deducting."
What happens when both checks happen at the same time?
"Use Redis DECR and reject if it goes negative."
What happens if Redis is down, or the decrement succeeds but the order is never persisted?
Your turn:
How would you design this inventory reservation API so concurrent buyers and retries never oversell the last item?
There’s a specific distributed-systems concept behind this.
And you’ll encounter it everywhere inventory, tickets, seats, coupons, and limited resources are involved.
Hot take:
A poorly designed monolith is often easier to fix than poorly designed microservices.
With microservices, one simple feature can involve:
4 network calls
3 retries
2 distributed tracing dashboards
1 incident nobody can explain
We traded deployment complexity for operational complexity.
When are microservices actually worth it?
“Write the code.
Review the AI’s code.
Debug why the AI’s code broke in prod.
Explain to the AI why its design is wrong.
Decide what the AI should never be allowed to touch.
Still own the outage.”
The job didn’t get simpler. It just added more layers of responsibility.
Unpopular opinion:
Adding an index is one of the most overused solutions to database performance problems.
Sometimes the real problem is:
A bad data model
An inefficient query
Fetching columns nobody needs
An application making 100 unnecessary queries
Not every slow query needs another index.
Agree or disagree? 👇
@atharvaadhumal Both solid.
Clock skew strongest, one pod’s clock behind, so fresh token’s iat/nbf looks future → 401. Retry hits healthy pod.
Stale key on new pod also possible.
Backend Interview:
Your API has 3 replicas.
Everything works perfectly.
Then traffic increases.
Suddenly, users receive this error:
401 Unauthorized
But here's the strange part:
Refresh the page → works.
Call the API again → works.
Same token. Same user. Same endpoint.
Logs show no authentication failures from the identity provider.
You restart one replica.
The errors disappear.
For a while.
No database issue.
No network outage.
No expired tokens.
What could cause this? 🤔
And why would restarting just one application instance temporarily fix the problem?
Bonus: How would you prove your hypothesis without restarting anything?
By 2028, the average junior engineer’s first year will look more like ‘reviewing and steering AI output’ than writing code from scratch.
If you’re hiring or mentoring juniors right now, are you preparing them for that or for the old world?
Your AI agent retries a failed payment tool call.
The first call actually succeeded, but the response timed out.
The retry charges the customer again.
This isn't an LLM problem.
It's a distributed-systems problem.
AI agents still need idempotency, timeouts, permissions and audit logs.
Which safeguard would you implement first?
Unpopular opinion:
A developer who writes code for 8 hours isn’t necessarily more productive than one who writes code for 4.
The other 4 hours might be spent preventing bugs, clarifying requirements, reviewing designs, or unblocking the team.
Lines of code are a terrible productivity metric.
Recently I interviewed a Senior Backend Engineer.
Strong candidate.
Load balancing? ✅
Caching? ✅
Database indexing? ✅
Horizontal scaling? ✅
Then I asked:
"You're building a product listing service.
A product becomes viral. Suddenly, 50,000 requests per second hit the same product ID."
Your database is struggling.
You add Redis.
Traffic drops at the database, and everything looks good.
Then the product price changes.
For the next 30 seconds, some users see the old price while others see the new one.
Worse, an old request finishes late and overwrites the updated cache entry.
How do you prevent stale data from coming back?"
"Just invalidate the cache."
What if an in-flight request repopulates it with stale data immediately after invalidation?
"Use a short TTL."
What if the business requires price changes to be reflected immediately?
"Use a distributed lock."
What happens when thousands of requests wait on that lock?
Now you've traded stale reads for a latency problem.
Your turn:
How would you design the cache update and invalidation flow to handle concurrent reads, writes, and delayed requests without serving stale prices?
There's a subtle distributed-systems problem hiding behind cache invalidation.
And it gets much harder when your cache is distributed across multiple application instances.
Unpopular opinion:
A 45-minute DSA round is a noisy way to measure whether someone will be a great software engineer.
It tests useful skills, but real engineering also requires debugging, trade-offs, code reviews, and handling failure.
One signal should never become the whole hiring decision.
Vibe coding is fine for prototypes. It’s dangerous for production systems that have real failure modes, compliance requirements, or users who will leave if latency or reliability slips.
How many teams are still pretending those two things are the same?
Recently I interviewed a Senior Backend Engineer.
Strong candidate.
Load balancing? ✅
Caching? ✅
Database indexing? ✅
Horizontal scaling? ✅
Then I asked:
"You're building a product listing service.
A product becomes viral. Suddenly, 50,000 requests per second hit the same product ID."
Your database is struggling.
You add Redis.
Traffic drops at the database, and everything looks good.
Then the product price changes.
For the next 30 seconds, some users see the old price while others see the new one.
Worse, an old request finishes late and overwrites the updated cache entry.
How do you prevent stale data from coming back?"
"Just invalidate the cache."
What if an in-flight request repopulates it with stale data immediately after invalidation?
"Use a short TTL."
What if the business requires price changes to be reflected immediately?
"Use a distributed lock."
What happens when thousands of requests wait on that lock?
Now you've traded stale reads for a latency problem.
Your turn:
How would you design the cache update and invalidation flow to handle concurrent reads, writes, and delayed requests without serving stale prices?
There's a subtle distributed-systems problem hiding behind cache invalidation.
And it gets much harder when your cache is distributed across multiple application instances.