Building a two-sided marketplace is a fascinating challenge that sits at the intersection of e-commerce, real-time systems, and distributed computing. Most engineers encounter the naive assumption that selling online is just "upload product, collect money," but the moment you add multiple concurrent buyers competing for limited inventory, the real complexity emerges. This is Day 2 of our 365-day system design challenge, and we're diving deep into how to architect a marketplace platform like Etsy where sellers thrive and buyers trust the experience.
Architecture Overview
A two-sided marketplace needs to handle three primary flows: seller operations, buyer discovery, and transaction management. At the core, you'll want separate services for product catalogs, user management, inventory tracking, and order processing. Sellers interact through a seller dashboard where they list products, manage inventory, and track fulfillment. Buyers use a search and discovery layer powered by an indexing service like Elasticsearch or similar, which constantly syncs with the product database to enable fast, relevant search results. The beauty of this separation is that search stays blazing fast even when inventory changes occur.
The real architectural tension appears when you introduce reviews, ratings, and social proof. Many platforms make the mistake of querying reviews synchronously during product page loads, which creates bottlenecks under traffic spikes. Instead, consider a denormalized approach where review aggregates (average rating, review count) are computed asynchronously and cached. A background job rebuilds these metrics periodically, ensuring your product pages remain fast while keeping ratings reasonably fresh. Payment processing deserves its own isolated service that communicates through well-defined APIs, keeping sensitive transaction logic separate from the rest of your platform.
The persistence layer is equally important. You'll want a primary database for transactional data (orders, users, seller accounts) but consider a separate read replica for analytics and search indexing. Cache layers like Redis become invaluable for storing frequently accessed data like product details, seller profiles, and inventory snapshots. This architectural decision directly impacts your ability to handle the tricky scenarios we'll explore next.
Design Insight: The Simultaneous Purchase Problem
Here's where things get interesting. What happens when two buyers try to purchase the last item simultaneously? This is a classic race condition, and how you solve it defines your marketplace's reliability. The naive approach is to check inventory, then create an order, then decrement stock. But between the check and the decrement, another buyer's request might slip through. The solution involves database-level constraints and transactions. Your inventory table should have a row-level lock that prevents two transactions from modifying the same product simultaneously. When a buyer attempts purchase, the order service initiates a database transaction that locks the inventory row, checks quantity, and atomically decrements it within the same transaction. If quantity is zero when the lock is acquired, the transaction fails, and the buyer sees an "out of stock" message. The first buyer to acquire the lock wins. While this approach adds latency per transaction, it's the correct trade-off for correctness in e-commerce.
Watch the Full Design Process
See how this architecture comes together in real-time. Our AI-powered system generated a complete diagram and design document in seconds, handling every component we discussed.
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. Whether you're tackling inventory management, payment processing, or review systems, InfraSketch helps you visualize the big picture before you write a single line of code.
Top comments (0)