eBay System Design: What to Expect

eBay runs system design as one round inside nearly every mid-level and senior onsite. It lasts about forty-five to sixty minutes. You get a single prompt, and it is one of eBay's own. Think of a wishlist that pings you when a price drops, a flash sale that cannot oversell, or a dashboard a seller reads to see what moved. The job is to design that marketplace piece well. Sharding a photo feed for a billion users is not the point.

Two facts shape every answer. The first is that eBay is a marketplace, so the hard parts are marketplace parts. Think of a price-drop event fanning out to millions of wishlists, a sale that must not sell one unit twice, or a buyer and a seller talking in real time. And eBay runs much of its own infrastructure. It is a Java and Spring shop stitched together with microservices and a Kafka backbone, and it expects you to design on that stack. Reach for a message bus when work fans out. Split the system into services. Defend the datastore behind each one.

The eBay angle

You are designing on eBay's own stack. eBay builds and runs much of its own infrastructure rather than leaning on a managed cloud, so a native answer reaches for the pieces eBay actually operates. A Kafka topic carries the price-drop events. Services own their own data. The follow-ups then go deep on the parts eBay runs itself. Expect questions on caching a hot read, which datastore holds the wishlists, how an update reaches a phone in real time, and where consensus is worth its cost. Name a component and be ready to defend it, because the engineer across from you maintains the real one.

How the round runs

The setup is plain. One prompt, one engineer, a shared virtual whiteboard, and roughly an hour to take the design from nothing to a shape you can defend. In the India loop the high-level round is often paired with a separate low-level design round. You might design a distributed system in one hour and model classes for an in-memory filesystem in the next. Neither a prompt list nor a scoring rubric is public. Where the numbers below carry a figure, read it as a steer toward where practice pays, not something eBay stands behind.

• Format: One HLD round, 45 to 60 minutes. System design is a single high-level round in nearly every mid-level and senior loop. You take one prompt end to end with an engineer on a shared whiteboard. India loops often add a separate low-level design round beside it.
• Domain: eBay's own marketplace. The prompt is one of eBay's surfaces, from a wishlist price alert to a flash sale to buyer-seller chat to a seller dashboard. Notifications and payments recur. A generic ride-share does not.
• Level weight: Light at SE-2, decisive higher. For Software Engineer 2 the round runs lighter and rarely sinks a candidate on its own. At SE-3 and above, including the India SSE title and the MTS track, it carries real weight, and senior loops push for more depth.
• Deep dives: On the infra eBay runs. Expect the interviewer to push on the parts eBay operates: caching a hot read, choosing the datastore, pushing updates in real time, and holding consistency when it matters. One reported round asked for RAFT by name.

The shapes that come up

The prompts cluster around eBay's marketplace, and one shows up more than any other. It is the price-drop alert. You put a product on a wishlist at a target price, price-drop events stream in, and the system notifies you when the price falls far enough. Around that signature sit the rest of the marketplace features and a handful of classics that still turn up.

The eBay angle

The prompt is an eBay marketplace, not a generic scale puzzle. Prep sites like to predict a ride-share or a photo feed. The people who actually sat the round describe something more specific: wishlist price alerts, a flash sale that cannot oversell, chat between a buyer and a seller, a dashboard a seller lives in. So rehearse the marketplace shapes, with notifications and payments close behind. Walk in ready to shard a photo feed for a billion users and you have prepared the wrong system, and the interviewer will steer you back inside the first ten minutes.

The designs in this section

Start with the price-drop notification system. It is the signature, and it teaches the core move: fan a stream of events out to millions of subscribers and deliver each one without dropping it or sending it twice. The marketplace service comes next, gathering the flash sale, the chat, and the seller dashboard, along with the Dropbox and TinyURL classics. Then the low-level design round, which flexes a different muscle. There you model classes for something like a parking lot or an in-memory filesystem, the same skill the Industry Coding Assessment leans on.

What the round rewards

The method is the standard arc, pointed at a marketplace. Scope first: who gets notified, what counts as a price drop, how many wishlists and events you are feeding. Sketch the API and the data model next, an entry on a wishlist, a price-drop event, a subscription to a product. Draw the high-level path and put Kafka where the fan-out happens. Then go deep where the interviewer leans, which is almost always delivery: getting a single drop out to millions of watchers, once each, without a flood.