Design Instagram Auction System
Design an auction system integrated with Instagram where users can post items for sale with images/videos, start auctions, place bids, and view auction results. Consider scalability challenges for celebrity users and high-traffic scenarios.
Asked at:
Meta
Instagram Auctions is a hypothetical auction marketplace built directly into Instagram, where creators and everyday users can list items with photos/videos, set time-bound auctions, and let followers bid in real time. Think of it as a blend of Instagram and eBay: rich media posts drive discovery, and a simple auction workflow determines a single winner. Interviewers ask this to test if you can extend a large social platform with a highly contended, real-time, correctness-critical feature. They’re looking for your ability to ensure fairness under simultaneous bids, handle bursty traffic from celebrity auctions, provide low-latency updates at scale, and orchestrate reliable end-of-auction workflows. Expect to reason about contention, ordering, durable timers, and push-based fanout, even if full internet-scale isn’t required for mid-level roles.
Hello Interview Problem Breakdown
Design Online Auction
System design answer key for designing an online auction platform like eBay, built by FAANG managers and staff engineers.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to create an auction on a post with start/end time, starting price, and bid increment rules.
Users should be able to place bids and receive immediate acceptance/rejection feedback based on the current highest bid and rules.
Users should be able to view auctions in real time, including the current highest bid, time remaining, and leading bidder.
Users should be notified when an auction ends; the winner should be able to complete checkout while others see the outcome.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Auctions are contention hotspots where a single winner must be determined unambiguously. In a system design interview at Meta, you’ll be evaluated on ensuring only one highest bid is accepted with clear tie-breaking and auditability. - Treat each auction as a single aggregate with optimistic concurrency (versioned row) so only one compare-and-swap of highestBid/leader succeeds per version. - Partition bid processing by auctionId (e.g., via Kafka or a sharded bid service) to preserve per-auction ordering and make bid submissions idempotent using a client-generated bidId. - Define deterministic tie-breaking (server receive time, then bidId) and perform accept/reject atomically, emitting an event for audit logs and user feedback.
Timers fail and processes restart; you need durable scheduling and idempotent state transitions. Interviewers want to see you re-validate state at wake-up and support extensions when last-second bids arrive. - Use durable timers (e.g., scheduled jobs in a DB table or a delayed-queue in Kafka) that retry; on wake-up, re-read the auction and finalize only if endTime has passed and state is ACTIVE. - Model a small state machine (ACTIVE -> ENDING -> ENDED) with idempotent transitions; if anti-sniping is enabled, extend endTime and reschedule instead of closing. - Emit an end-of-auction event to trigger notifications and the payment window; make the close operation idempotent to avoid double winners.
Real-time experience is central to user trust and excitement. The challenge is efficient, reliable fanout from a few write events to many subscribers connected across edge servers. - Use server push (WebSockets or SSE) for low-latency updates and fall back to polling for unsupported clients; publish updates to per-auction channels over a pub/sub backbone so any edge can deliver. - Coalesce/batch rapid updates (e.g., at 100–200 ms) to reduce bandwidth; compress payloads and drop superseded updates to handle slow clients. - Store subscription metadata and last-known state in a shared cache (e.g., Redis) so reconnecting clients can quickly catch up without hitting the primary store.
The last moments of an auction cause extreme write contention and bursty traffic. Your design should preserve correctness while shedding non-critical work under load. - Front bids with a durable, partitioned log keyed by auctionId (e.g., Kafka) and keep the hot path minimal: validate, CAS highest bid, emit event; push secondary work (indexing, analytics) to async. - Apply per-auction rate limiting/admission control and reject obviously invalid bids early at the API; use circuit breakers to isolate overheated auctions. - Pre-provision capacity for known celebrity events and consider priority handling; if necessary, degrade non-critical updates (e.g., viewer counts) while preserving bid processing.
Relevant Patterns
Relevant patterns that you should know for this question
All bidders converge on a single auction record, creating a hotspot. You must coordinate concurrent writes with optimistic concurrency or short-lived locks, define deterministic tie-breaking, and ensure only one winner is recorded.
Bidders and viewers expect sub-second visibility into the leading bid and time remaining. A push-based architecture (WebSockets/SSE + pub/sub fanout) is essential to deliver timely updates across many edge connections.
Auction end scheduling, soft-close extensions, notifications, and payment windows require durable timers and resilient background workers that survive restarts and perform idempotent state transitions.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL offers strong transactional guarantees, making it a solid source of truth for auctions and accepted bids. It supports optimistic concurrency on the auction aggregate and can be sharded by auctionId as write volumes grow.
Similar Problems to Practice
Related problems to practice for this question
Both require fairness under concurrent bidding, a single authoritative winner, anti-sniping or closing logic, and post-auction workflows like notifications and payments.
Both systems involve real-time fanout to massive audiences, connection management across edges, coalescing updates, and handling bursty engagement patterns.
Integrating auctions into Instagram leverages the same media posting, discovery, and feed surfaces, requiring consideration of how new auction objects interact with existing content pipelines and notifications.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Using cache as the source of truth for highest bids
Accepting bids into an in-memory cache or ephemeral store without a transactional write to persistent storage risks conflicting winners and irrecoverable states after failures, eroding user trust.
Coarse-grained locking or scanning all bid rows to compute the winner
Broad locks or SELECT MAX(...) FOR UPDATE serialize bidders and collapse under load, creating latency spikes and deadlocks on hot auctions. Prefer optimistic concurrency on a single auction aggregate.
No partitioning or idempotency in bid processing
A single queue/consumer can reorder or drop bids across auctions, and missing idempotency causes duplicate acceptance on retries. Partition by auctionId and require a unique bidId to ensure fairness and correctness.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late September, 2025
Meta
Mid-level
Design a system like Instagram auction.
Late August, 2025
Meta
Manager
Late August, 2025
Meta
Staff
Your account is free and you can post anonymously if you choose.