Building a two-sided marketplace is one of the most interesting system design challenges you'll encounter. You're not just designing a single application, you're orchestrating interactions between two user types, managing inventory in real-time, and ensuring trust through reviews and ratings. This Day 2 challenge explores the architecture behind platforms like Etsy, revealing the complexity hidden beneath a simple "buy" button.
Architecture Overview
A marketplace platform requires several core components working in concert. The user service manages both buyers and sellers, handling authentication and profile management for each group. The product catalog stores listings with inventory counts, search indexes, and filtering capabilities. The order management system processes purchases, tracks status, and coordinates between buyer and seller. Payment processing handles transactions securely, while a notification service keeps users informed of order updates, new messages, and reviews.
The real magic happens in how these components communicate. When a buyer searches for products, the search service queries a denormalized index optimized for fast retrieval rather than joining tables in real-time. When a purchase happens, the order service must coordinate inventory updates, payment processing, and seller notifications. The review system creates a feedback loop that builds trust and influences search rankings.
A critical design decision is whether to use a monolithic database or split data stores. Many marketplace architects choose a hybrid approach: relational databases for transactional consistency (orders, payments, inventory), document stores for flexible product metadata, and search engines like Elasticsearch for fast queries. This separation allows each component to scale independently based on its specific load patterns.
Design Insight: The Race Condition Problem
Here's where things get tricky: what happens when two buyers purchase the last item simultaneously? Without proper safeguards, both transactions could succeed, leaving you unable to fulfill one order. This is a classic race condition that requires careful handling.
The solution involves inventory locking mechanisms. When a buyer clicks purchase, the system must atomically check inventory and decrement the count in a single transaction. Using database-level locks or implementing optimistic locking with version numbers prevents overselling. Some platforms add an extra buffer: reserving inventory for a short time window (typically 5-10 minutes) during checkout. If payment fails or the cart is abandoned, the inventory reverts to available. This approach balances user experience with data consistency, though it requires a background job to clean up expired reservations. Distributed systems add another layer of complexity, necessitating consensus mechanisms or message queues to ensure state consistency across multiple servers.
Watch the Full Design Process
See how AI generates this entire architecture diagram in real-time, including the inventory management layer and the mechanisms for handling concurrent purchases:
Try It Yourself
Ready to design your own marketplace? Head over to InfraSketch and describe your system in plain English. In seconds, you'll have a professional architecture diagram, complete with a design document.
Top comments (0)