Adyen System Design: What to Expect

Two flavors of design round show up in the Adyen loop. Which one you get varies. It depends partly on the team and partly on the interviewer. The first is a payments prompt drawn straight from what Adyen does: design a payment service provider, and trace a single card transaction through every component it touches. The second is a generic distributed-systems prompt of the kind you would meet anywhere. It might be a car-pool service that matches a rider going from A to B onto a vehicle. It might be an event-ticket booking system, or the small classic of rewarding the one-millionth visitor to a campaign page. Both are reported often enough that you prepare for both.

The round runs around fifty-five minutes and carries real weight even at mid-level. An SDE2-grade loop still has a dedicated design conversation. The interviewer wants the usual arc. Pull requirements out of a thin prompt, name the core entities, sketch the APIs, then draw a high-level design and defend it. The flavor changes where the difficulty lives. A generic prompt puts the pressure on scale and availability. A payments prompt puts it somewhere most candidates rehearse far less: getting money movement exactly right.

The Adyen angle

Adyen is a payment service provider, so in the payments flavor "correct" means an amount, not an approximation. When you design a social feed, a dropped write costs a lost post and the user reposts it. Now design the pipe that authorizes a card, captures the funds and settles them to a merchant. There, a dropped or doubled write is real money in the wrong place, and no user action puts it back. So the payments prompt rewards a different instinct. The question underneath is rarely "how do you take more traffic." Picture a customer who taps pay once. The network times out, the client retries, and the acquirer may already have charged the card. How do you guarantee the shopper is charged exactly once, and the merchant's ledger reflects exactly that? Prepare to reason out loud about idempotency and consistency for money under retries.

The prompts that recur, and how they split

None of these is published as a rubric, so treat the list as terrain. Recognize the flavor early. The moment you hear the prompt, you know whether the hard part is money correctness or raw scale, and you steer accordingly. Candidates report the four below most often, though any loop can depart from them.

• Payments flavor: Design a payment service provider. The signature prompt, and the one that looks most like Adyen's actual product. You take a card payment from a shopper's tap through authorization, capture, and settlement. Trace request and response across each component: the merchant integration, Adyen's platform, the acquirers and card networks, and the ledger that has to reconcile at the end. The interviewer listens for that component-by-component tracing.
• Generic flavor: A car-pool matching service. A rider wants to go from A to B and joins a vehicle already heading that way. Standard distributed-systems fare: model riders, drivers, and trips. Define the matching API, then reason about how you find nearby vehicles and scale the matcher. No payments knowledge required. The fundamentals you would bring anywhere carry it.
• Generic flavor: An event-ticket booking system. Reported as an IPL ticket-booking build: requirements, then core entities (events, seats, bookings), then APIs, then the high-level design. The interesting tension is holding and confirming a seat without overselling it. That is a consistency problem in miniature, so some of the same money instincts transfer even though the domain is generic.
• Warm-up flavor: The one-millionth-visitor problem. Reward the millionth visitor to a marketing-campaign page. Small on the surface. Underneath, it is a counting-under-concurrency question. Many web servers increment a shared counter at once, and exactly one request must win the millionth slot without a race. A tidy probe of atomicity and coordination that can open a round or sit inside a larger one.

The signature: designing a payment service provider

When the round turns payments, the prompt is deceptively short. The depth is all in the details. You are asked to design the platform that sits between a merchant and the card networks, and to walk a single transaction through it end to end. Start at the boundary. A shopper submits a payment and the merchant's server calls your API. From there you own the routing, the authorization, the eventual capture and settlement, and the record-keeping that has to balance. A handful of concerns come up almost every time the prompt runs, whichever way you draw the boxes.

The Adyen angle

Write the money movement down before you do anything clever with it. Treating the ledger as the source of truth, with everything else a view on top, reads as senior here. Record the authorization and the capture as immutable entries first. Then derive balances, merchant payouts and reporting from that record. A bug in a downstream service can then be replayed away instead of corrupting the one thing that has to be right. When the interviewer pushes on a failure, a retry or a partial outage, answer from the ledger. Say what is written, what is provisional, and how the system reconciles the two afterward. Protect the record of money first, then layer routing and reporting on top.

When the prompt is generic instead

Draw a car-pool matcher or a ticket-booking system and the texture changes. Now the pressure is familiar. Model the entities cleanly, define a sane API, and reason about how the thing scales as users and traffic grow. Standard distributed-systems practice maps straight onto it. Lead with the usual moves: clarify requirements, size the load, then design outward from the data model. One habit still pays off even here. The money-correctness instinct transfers to any place two requests compete for one scarce thing. Overselling the last seat in a booking system has the same shape as double-charging a card. Treat the seat hold as a consistency question. Calling it a caching question is a hand-wave.

The Adyen angle

Let the prompt tell you what the hard part is, then aim there. Do not reach for a rehearsed template regardless of what you were asked. Treating a payments prompt as a throughput problem misses it. Smothering a generic prompt in payments jargon reads as forcing a script. Listen for the tell in the first minute. If the prompt is about moving money, the interviewer is waiting to hear idempotency, ledgers and reconciliation. If it is about matching riders or selling seats, they want a clean data model and an honest scaling story, with a nod to the one place things contend. Match your depth to the prompt in front of you.

The one worked design in this section

The payments flavor is the Adyen-shaped one, and most candidates have never rehearsed it. So this section puts its weight there. A single worked design carries the section: a payments platform, built the way the signature prompt asks for it. It puts the whole flow on the table at once. A card transaction runs from the merchant boundary through routing and authorization to capture, settlement and a ledger that reconciles. The exactly-once and consistency reasoning stays concrete. Build it cleanly once and the moves transfer. The same idempotency and ledger instincts carry to any payments prompt, and the scarce-resource reasoning underneath it carries to the generic booking and counting prompts beside it.

Common questions