Backend Developer Interview: System Design Challenges

Recently, I went through a Backend Developer Intern interview at FPT Telecom where the tech lead presented three interesting system design problems. I was able to solve the first case, had less experience with the second, and while I knew Redis, I hadn't applied it to solve the third case. This article breaks down these three cases and their solutions.

Case 1: Handling Race Conditions in Inventory Systems

The Problem: Imagine an inventory system with only one product left in stock. What happens when two users simultaneously click the purchase button? How do we prevent the inventory count from going negative?

The Solution: Database Transactions and Locking

This problem directly relates to the ACID properties of database systems, specifically isolation and consistency. My approach was to implement pessimistic locking within database transactions.

Here's how it works in practice:

1. When User A initiates the purchase process, the system begins a database transaction and uses SQL commands to lock the specific product data row.
2. Meanwhile, User B submits their purchase request. However, because the product data is locked, User B's request must wait.
3. Once User A completes the payment, the inventory count is updated to 0, and the transaction is committed (releasing the lock).
4. Now User B's request can proceed, but since the inventory is now 0, the system throws an "out of stock" exception.

This isolation mechanism ensures the inventory count never goes negative, maintaining data consistency. The trade-off here is reduced concurrency during high-demand periods, as legitimate users may experience waiting times.

Case 2: Handling Missing Webhooks for Payment Confirmation

The Problem: A system integrates with VNPay payment gateway. A customer successfully pays, the bank deducts the funds, but just as VNPay is about to call back to our server with the result, the client's network connection drops. How does the system ensure the order doesn't remain in "Pending Payment" status indefinitely?

The Solution: Active Polling with Cron Jobs

Webhooks are inherently passive communication channels - they only work when the other party initiates contact. To address this reliability issue, the backend needs to implement an active polling mechanism.

Here's the solution I proposed:

1. Implement a cron job that runs every 5-10 minutes.
2. This job scans the database for orders stuck in "Pending Payment" status for an extended period.
3. For each pending order, the system takes the transaction ID and proactively calls VNPay's API to check the payment status.
4. If VNPay confirms the payment was successful, the system automatically updates the order status to "Completed".

This active polling approach ensures that even if webhooks fail, payment confirmations will eventually be processed. The trade-off is increased system complexity and additional API calls to the payment provider, which may have rate limiting or associated costs.

Case 3: Handling High Traffic During Flash Sales

The Problem: During special promotions or flash sales, hundreds of thousands of users access the application simultaneously. The database would inevitably become overloaded and crash. What solutions can prevent this scenario?

The Solution: Caching and Rate Limiting

When dealing with sudden traffic spikes, directly querying the database for every request would quickly overwhelm it. The solution involves implementing both caching and rate limiting strategies.

Caching:

• Store frequently accessed static data from the database in an in-memory cache like Redis.
• Redis operates in memory, making data retrieval significantly faster than database queries.
• When thousands of requests arrive simultaneously, the backend can serve responses directly from Redis, dramatically reducing database load.
• For flash sales, product information, inventory counts, and other static data can be cached effectively.

Rate Limiting:

• Implement rate limiting to protect against spam bots or DDoS attacks.
• Configure limits on the number of requests per second from a single IP address.
• If an IP exceeds these limits by rapidly reloading pages, block it to protect server resources.

The trade-off with caching is potential data staleness - cached information may not reflect real-time inventory updates. The trade-off with rate limiting is potentially blocking legitimate users in high-traffic scenarios.

Conclusion

These three cases highlight fundamental challenges in backend system design: maintaining data consistency under concurrent access, ensuring reliable external integrations, and handling extreme traffic loads. Each solution involves trade-offs between consistency, availability, and performance - a common theme in distributed systems.

For backend developers preparing for interviews, understanding these problems and their solutions is valuable. However, it's equally important to have a strong grasp of data structures and algorithms (DSA), SQL, and other core computer science fundamentals. Additionally, honesty about one's experience level is crucial - fabricating skills on a resume inevitably leads to problems down the line.

One additional question I encountered was comparing stateful and stateless approaches to user session management, but that will be covered in a separate article as this one has already grown quite comprehensive.