Wishlist & Registry Architecture: Preventing Double Gifts at Scale
Imagine the chaos when two guests unknowingly purchase the same expensive wedding gift, or a baby registry item sells out because the purchase system didn't properly coordinate inventory. A well-designed wishlist and registry system needs more than just a pretty list interface. It requires careful coordination between services to prevent duplicate purchases, manage real-time inventory, and keep everyone informed. Today, we're exploring the architecture that makes this seamless experience possible.
Architecture Overview
A robust wishlist and registry system sits at the intersection of several critical concerns: user management, inventory control, notifications, and payment processing. The architecture typically involves a core registry service that manages lists and items, an inventory service that tracks stock levels and reservations, a notification engine that alerts users to price changes and availability, and a payment service that coordinates transactions. These services communicate through well-defined APIs and event streams, ensuring data consistency even when multiple purchases happen simultaneously.
The design separates read operations from write operations, allowing the system to handle frequent list browsing without straining the services that modify state. When a user adds an item to a registry, that's a write operation that updates the database. When someone views the registry to see what's available, that's a read operation that can be served from cached data. This separation means a registry can handle thousands of concurrent viewers without slowing down the purchase flow.
Real-time coordination is essential here. The system uses an event-driven architecture where significant actions, like a purchase completion or price change, trigger events that ripple through other services. A payment service publishes a "purchase_completed" event, which the inventory service listens to and uses to update stock levels, while the notification service simultaneously sends alerts to waitlisted users. This approach keeps everything synchronized without requiring complex distributed transactions.
Design Insight: Preventing Duplicate Purchases
So how does the system actually prevent the nightmare scenario where multiple people buy the same item from a shared registry? The answer lies in optimistic locking and inventory reservations. When a guest initiates a purchase, the system reserves that item in inventory temporarily (usually for 10-15 minutes). If another guest tries to purchase the same item during this window, they see it as temporarily unavailable. The reservation is tied to the transaction, so if payment fails, the item is immediately released back to available status.
Additionally, the registry item itself maintains a quantity field that decrements with each completed purchase. Before confirming any transaction, the system performs a final validation check: is the quantity still greater than zero? Only items with confirmed inventory are allowed to proceed to payment. This dual-layer approach, combining reservations and final validation, prevents overselling even under high concurrency. The system can also implement a "gift tracking" feature where completed purchases are marked against the registry item, giving other users instant visibility into what's already been purchased.
Watch the Full Design Process
See this architecture come to life as we generate the complete system design in real-time using InfraSketch. Watch the diagram build, components connect, and design decisions emerge:
Try It Yourself
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.
This is Day 18 of our 365-day system design challenge. What architectural pattern would you tackle next?
Top comments (0)