How to pass the BharatPe SDE-2 system design interview

BharatPe completely reshaped the Indian fintech ecosystem. They started by putting a simple QR code on merchant counters, then quickly followed up with the now-ubiquitous merchant soundbox. If you're a Software Development Engineer 2 (SDE-2) candidate, the system design interview here is often the ultimate test of your architectural chops. You aren't just building another standard CRUD application. Instead, you'll be designing a high-throughput, low-latency IoT orchestration engine. This system has to bridge cloud microservices with millions of physical devices running on spotty 2G and 3G networks. Passing this round requires proving you deeply understand network protocols, idempotency, and distributed systems.

The BharatPe SDE-2 Hiring Process

Before we tackle the architecture, let's look at the gauntlet you'll actually run. The BharatPe SDE-2 interview process typically spans three to four weeks. It leans heavily on practical engineering skills rather than abstract theory. These rounds specifically test your coding speed, how well you structure complex applications, and your foresight when it comes to system design.

The Soundbox Challenge: Core Requirements

When the interviewer asks you to design the soundbox alert engine, start by locking down the exact requirements. A very common mistake is rushing straight to the whiteboard to draw boxes. Don't do that without first defining the strict constraints of IoT devices.

• Functional: Receive a payment success webhook from a payment gateway or UPI switch.
• Functional: Identify the specific soundbox mapped to the merchant's QR code.
• Functional: Deliver a message to the device triggering a localized audio playback.
• Non-Functional: Extremely low latency. The audio must play within 1 to 2 seconds of the payment success.
• Non-Functional: Strict idempotency. The device must never announce the same payment twice.
• Non-Functional: High scale. Support over 5 million concurrent active device connections.

High-Level Architecture: From Payment Gateway to IoT Device

The journey of a payment alert kicks off at the UPI switch or banking partner. When a customer scans a BharatPe QR code and completes a payment, the bank immediately fires a webhook to BharatPe's Payment Gateway service. This service validates the payload, updates the core ledger, and drops an event into a distributed message queue like Apache Kafka. Next, a dedicated Notification Orchestrator service consumes that Kafka event. It queries a caching layer to find the merchant's active soundbox device ID, then pushes the payload right to the IoT connection layer. This connection layer is the truly critical component, as it has to maintain millions of persistent connections without breaking a sweat.

How do we maintain millions of concurrent connections efficiently?

This is easily the most critical question your interviewer will ask. You simply can't use standard HTTP polling here. If 5 million devices poll your server every single second, you'll effectively DDoS your own infrastructure. Worse, the devices will drain their batteries and cellular data allowances almost instantly. WebSockets are definitely a step up since they offer persistent TCP connections. However, they carry a heavy handshake overhead and completely lack built-in message delivery guarantees.

The right architectural choice for this problem is MQTT (Message Queuing Telemetry Transport). MQTT is an extremely lightweight pub/sub messaging protocol built specifically for constrained devices and low-bandwidth, high-latency networks. It utilizes a binary payload with a tiny 2-byte header, which drastically reduces data usage. In your design, you'll want to place an MQTT Broker cluster—using technologies like EMQX or AWS IoT Core—behind a network load balancer. From there, each soundbox establishes a persistent TCP connection to the broker and subscribes to a unique topic, like merchant/12345/alerts.

How do we ensure low latency and strict idempotency?

If a merchant hears 'Received fifty rupees' twice for a single transaction, it completely destroys their trust in the system. Because of this, you must handle idempotency at two distinct layers: the backend and the device firmware. When the bank fires the webhook, it includes a unique Bank Reference Number (RRN). Your backend needs to use a fast caching layer like Redis to process this. We perform a SETNX (Set if Not Exists) operation using that RRN as the key, typically with a 24-hour TTL. If the operation returns false, the bank is just retrying an already processed webhook, so we can safely drop it.

Network unreliability still poses a threat. The MQTT broker might send the message to the device perfectly fine, only for the acknowledgement packet to get lost in transit. MQTT offers different Quality of Service (QoS) levels to handle this. QoS 2 (Exactly Once) guarantees no duplicates, but it forces a 4-step handshake that adds severe latency over a spotty 2G connection. A much better architectural trade-off is using QoS 1 (At Least Once). It's significantly faster because it only needs a 2-step handshake, though it does mean duplicates can occasionally reach the device. To counter this, the soundbox firmware has to maintain a rolling buffer of the last 50 processed message IDs. When a new message arrives, the firmware checks that local buffer and simply ignores the payload if the ID is already there.

How do we manage offline states and device telemetry?

Merchants frequently unplug their soundboxes, or the devices simply lose cellular signal. Your backend needs to know in real-time if a device drops offline so it can fall back to sending an SMS to the merchant's phone instead. MQTT solves this elegantly with a feature called Last Will and Testament (LWT). When a soundbox connects to the broker, it registers a 'Will' message. If the broker detects that the TCP connection dropped ungracefully—meaning no standard disconnect packet was sent—it automatically publishes this Will message to a status topic. A backend service subscribes to that status topic and updates the device's state to 'Offline' in a database like DynamoDB or Cassandra.

When it comes to telemetry, the device shouldn't stream data constantly. Instead, it should publish a heartbeat every 5 to 10 minutes containing its battery level, signal strength, and current firmware version. This data gets routed to a time-series database. That way, the operations team can proactively replace failing devices well before the merchant even has a chance to complain.

How do we optimize data usage for audio playback?

A candidate might naively suggest sending the actual audio file—like an MP3 or WAV—over the network for every single transaction. Doing this would cause massive latency and result in astronomical cellular data bills. The right approach here is edge processing. The soundbox comes pre-loaded with a library of audio snippets stored directly in its flash memory. We're talking basic building blocks like numbers 0-9, hundred, thousand, 'received', and 'rupees'. The MQTT payload coming from the server is just a tiny byte array or a short string that indicates the sequence of audio IDs to play. For example, sending a payload of '101,50,102' tells the device firmware to stitch together the local files for 'Received', '50', and 'Rupees'.

Ace the BharatPe System Design Interview with AcePrompt AI

Designing an IoT orchestration platform means balancing deep theoretical knowledge against highly practical trade-offs, especially regarding network unreliability and hardware constraints. Communicating those trade-offs clearly while under the pressure of a live interview is incredibly tough. That's exactly where having a real-time copilot can make the difference between a painful rejection and a strong hire.

AcePrompt AI listens to your interview in real-time and provides structured, context-aware suggestions right on your screen. Say your interviewer suddenly pivots from asking about MQTT to grilling you on how you'd handle database sharding for the device registry. AcePrompt instantly surfaces the optimal strategies. It helps you maintain your momentum and confidently showcase your true engineering depth.