Mohit Gupta

Ex-Staff Engineer @LinkedIn | Helping engineers crack Sr/Staff+ System Design interviews | 15+ yrs building distributed systems | 1:1 mentorship

[Mohit Gupta @staffsignal]

@system_monarch This is the real progression. Most people try to memorize components. The useful skill is repeatedly asking what breaks at the next order of magnitude, then adding only what that failure demands.

[Mohit Gupta @staffsignal]

@asmah2107 Useful framing. Partial failures, replication lag, and at-least-once semantics don’t disappear just because the workload is agents. A lot of “AI system” pain is still distributed systems pain.

[Mohit Gupta @staffsignal]

Interviewed a Senior Backend Engineer recently.

Knew Redis, Kafka, microservices, system design.

Then I asked:

You need to charge a customer exactly once.

Client sends:
POST /payments
Idempotency-Key: abc123

Flow:
1. Check if this key was already processed
2. Charge the payment provider
3. Mark the key as completed

Now the failure case:

You charge the provider successfully.
The app crashes before saving that the key was processed.

Client retries with the same Idempotency-Key.

What happens?

Do you charge again?
How do you make this safe across retries, crashes, and concurrent requests?

Silence.

Your turn.

[Mohit Gupta @staffsignal]

Interviewed a Senior Backend Engineer recently.

Knew Kafka, Redis, microservices, system design.

Then I asked:

You need to send a notification after an order is placed.

Flow looks simple:
1. Write order to the database
2. Publish event to Kafka
3. Notification service consumes and sends the message

Now the failure case:

The database commit succeeds.
The app crashes before publishing to Kafka.

Order exists.
Customer never gets the notification.

Or the opposite:

Event is published.
Database transaction rolls back.

Customer gets “Order confirmed”
But there is no order.

How do you publish the event reliably only when the database transaction succeeds?

Silence.

Your turn.

[Mohit Gupta @staffsignal]

@e_opore Useful topic. Most teams reach for 2PC too quickly. In practice, sagas or outbox-based flows are usually more operable once you accept that perfect atomicity across services is expensive.

[Mohit Gupta @staffsignal]

@Akintola_steve This is the right habit. One problem a week with clear questions around failure, bottlenecks, and scale builds better judgment than trying to memorize a large set of architectures.

[Mohit Gupta @staffsignal]

@krishnapro_ The concepts that usually matter most in real systems are the ones around failure and data movement - timeouts, retries, idempotency, backpressure, and how state is partitioned and recovered.

[Mohit Gupta @staffsignal]

@anurag_gharat Clean overview.
One thing worth adding: an API gateway can become a bottleneck or single point of failure if too much logic lives there. Keeping it focused on routing, auth, and cross-cutting concerns usually ages better than turning it into a mini application layer.

[Mohit Gupta @staffsignal]

@SidJain_80 Good breakdown of the storage choice.
Message ordering is the subtle part. Local sequence numbers per channel are often enough and much simpler than a global generator, as long as you only need order within a conversation.

[Mohit Gupta @staffsignal]

@tanujDE3180 You don’t return 10 million records in one response.
Pagination helps for interactive use. For bulk export, async generation + download link is usually the right model. Streaming can work too, but only if the client and timeouts are designed for it.

[Mohit Gupta @staffsignal]

Interviewed a Senior Backend Engineer recently.

Knew Redis, Kafka, microservices, system design.

Then I asked:

You have 20 application servers.
You need a rate limit of 100 requests per minute per user.

Requests can hit any server.
Servers scale up and down.
You can’t keep the counter in memory on one machine.

How do you enforce the limit consistently?

He said: “We’ll use Redis.”

Okay. Where do you store the counter?
What happens when 500 requests for the same user arrive at the exact same time?
Which algorithm do you use — fixed window, sliding window, or token bucket?
And what happens when Redis is slow or briefly unavailable?

Silence.

Your turn.

[Mohit Gupta @staffsignal]

@grok @microcp2mltibgr When can we expect it to reach 100

[Mohit Gupta @staffsignal]

@grok @microcp2mltibgr What are end of year targets for usdinr

[Mohit Gupta @staffsignal]

@krunalbuilds Agree. Once the read path stays simple and predictable, ranking and personalization become much easier to layer on without hurting latency.

[Mohit Gupta @staffsignal]

@tanujDE3180 Well put. The decision almost always comes down to which constraint you optimize for first revocation speed or horizontal scale.

[Mohit Gupta @staffsignal]

@angshuhere Solid progress.
L4 vs L7 is one of those distinctions that becomes very real once you care about TLS termination cost and content-based routing. Consistent hashing is a natural next step once you start thinking about cache or shard rebalancing.

[Mohit Gupta @staffsignal]

Good overview of the tradeoffs.
The operational cost is the part that usually gets underestimated especially distributed transactions, debugging across services, and the extra latency from network calls. Microservices pay off when team ownership and independent scaling matter more than simplicity.

[Mohit Gupta @staffsignal]

@SidJain_80 Clean high-level split.
The stateful chat service is usually the hardest part. This includes connection management, presence, and making sure a user stays pinned to the right server without creating hot spots or painful reconnections during deploys.