What to Expect in the Zalando System Design Interview

Expect one hour on a design problem taken from online retail. Zalando calls this stage the system design and architecture interview. The company states that it gives you a short problem description and asks you to design a system that solves it. Zalando also names the six areas it grades: architecture, scalability, technology choices, resilience, operational excellence, and security. Candidates report questions about a shopping cart, a payment system, and a store for a small business. You will not get an abstract puzzle, so expect a retail problem in which real customer money moves.

The Question Types

Cart and checkout. One reported question asked for a shopping cart design, including the API endpoints, the HTTP error codes, and the difference between a guest user and a signed in user. It also asked how a guest cart joins an account after sign in. This fits Zalando's public API guidelines, which set rules for how its services expose endpoints and errors.

Payments and orders. Candidates also report a payment system question, which is harder than it first appears. The difficulty comes from idempotency, from retries, and from keeping the payment and the order in agreement. Idempotency means the same request can arrive twice without charging the customer twice.

Catalog, search, and stock. Zalando's store lists a very large catalog from many brands, in many languages, so search and stock questions follow from the product itself. The difficulty comes from index updates, from language differences, and from two customers wanting the last item in the same second.

Event driven services. Zalando replaced one large application with many small services, and it built an event broker called Nakadi to connect them. An event broker is a service that carries messages from producers to consumers. Expect questions about ordering, duplicates, and consumers that read events more slowly than producers write them.

What the Interviewer Grades

Zalando names the six areas, so answer each one out loud without waiting. Start with the requirements and the expected scale, then name every trade-off you accept instead of hiding it. Cover resilience by saying what happens when the payment service becomes unreachable.

Cover operational excellence with the metrics, the alerts, and the person who gets paged at night. Cover security last, but do cover it, because customer data and payment data both carry legal rules in Europe. Candidates report interviewers who ask the cost of each choice, so state your numbers first.

A Walkthrough: Design the Cart and Checkout

1. Requirements (5 minutes). State that the cart serves both guests and signed in customers, across many countries and currencies. Add two hard requirements: the cart still exists after the customer closes the browser, and checkout never charges a customer twice.

2. The API. Define the endpoints first, because API first is a stated Zalando principle. Use one cart resource per customer, with operations to add, update, and remove items. Return a clear error code for an item that is out of stock, not a generic failure.

3. Cart storage. Store the cart in a key value store, keyed by the customer identifier or by a guest token. Keep the record small: item identifiers, counts, and the time each item was added. Do not store the price in the cart, and read it at display time instead, because prices change.

4. Guest to account merge. When a guest signs in, combine the guest cart with the account cart. Decide the rule for an item that appears in both, and say that rule out loud.

5. Stock and reservation. Check stock at display time and again at checkout. Reserve stock for a short window during checkout, then release it if payment fails. Explain why you did not reserve at the moment the item was added.

6. Checkout and payment. Write the order first, then call the payment service with an idempotency key. Publish one order event so that fulfillment, invoicing, and email all act on it separately, which is the work an event broker exists to do.

7. Failure and operations. Retry a failed payment call with the same key, so a repeated attempt cannot charge the customer again. If the payment service is unreachable, show a clear message and keep the cart intact. Name the metrics you would alert on, such as checkout error rate and payment latency.

8. Scale. Cache the catalog data the cart page reads, and partition cart storage by customer. Under heavy load, reduce the page to a read only view instead of failing the whole request.

Common Mistakes in This Round

• Skipping the API. Zalando publishes its API guidelines in public, so a design with no endpoints and no error cases fails the company's own standard.
• Treating payment as one call. Preventing a double charge is the central difficulty of this question, so say the word idempotency early and explain how your key works.
• No operations story. The company grades operational excellence by name, which means a design without metrics, alerts, and an on-call plan is unfinished.
• Forgetting many countries. Currency, tax, language, and delivery rules all differ by market, so a design that assumes one country is incomplete.
• Silence on security. Payment data and customer data both carry strict legal rules in Europe, so name those constraints briefly instead of skipping them.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the caches, queues, and databases a cart and checkout design needs.
• Study the harder cases. Advanced System Design Interview, Volume II helps with consistency, replication, and failure handling, which this round grades directly.
• Rehearse the eight steps. Say the walkthrough above out loud in under 40 minutes, with a diagram.
• See the whole process. This is stage four of the Zalando interview process, and the motivation question comes in the first call.
• Know what follows. Timing after the final rounds is covered in how long it takes to hear back.