Product Architecture Interview: User Journeys, APIs and Data Models

You spend the round on servers, as an infra (infrastructure) round would want, and run out of time before showing what the app calls. A product architecture interview is about a feature that works for its users. Boxes drawn without users, API calls and tables answer a different question.

Picture a common setup. A backend developer in Bengaluru with three years of experience gets the prompt: design event invites and RSVPs for a social app. The setup is made up, but every design choice tested below ran on SQLite, a small database that runs inside a program.

An RSVP is a guest's reply to an invite: going, maybe or can't go. The developer opens with a CDN, a load balancer and a database split across machines by event ID.

A CDN (content delivery network) is a set of servers that keep copies of files close to users. A load balancer spreads requests across servers. Splitting one database across machines is called sharding.

At minute 30 the interviewer asks what happens when a guest on patchy mobile data taps Going, the request times out and the app resends it. The diagram has no answer, because it never showed the reply call or the table behind it.

This guide answers that prompt end to end, the way a product round wants it. The same event-invites feature runs through every section.

You need these terms. Each one is tied to the event-invites example.

• User journey: the steps one kind of user takes to finish one task. Example: a guest opens an invite and replies Going.
• API and endpoint: an API (application programming interface) is the set of requests an app can send to a server. An endpoint is one of those requests, such as reply to this event.
• Resource and method: a resource is a thing the API exposes by name, such as an event or its guest list. HTTP, the protocol apps use to talk to servers, gives methods that act on it: GET reads, POST creates, PUT replaces, PATCH changes some fields.
• Data model: the tables, their columns and the keys that link them. A primary key is the column, or set of columns, that picks out exactly one row.
• Idempotent: safe to repeat. Sending the same idempotent request twice leaves the server in the same state as sending it once.
• Pagination and cursor: pagination returns a long list in pages. A cursor is a marker for the last item you saw, so the next page starts right after it.
• Client: the app or web page that calls the API, often a phone on a slow or flaky network.

A product architecture interview is a design round about one user-facing feature. Expect to be judged on how well the design serves the people using it: the journeys, the API contract, the data and the edge cases.

The name is not a standard term, and companies label their rounds differently. In this guide it means any design round that starts from a product feature rather than a scale target. Ask your recruiter which kind of design round you have.

The same prep post gives a product-style prompt: "Tell me how you'd design a client-server API to build a rich document editor". Its follow-up questions focus on the client and the contract.

It asks how the client requests the document from the server, and how to show bold and italics "in our API response". It also asks how to add features on the server "without breaking older clients".

The same product design section has a second prompt: "Tell me how you'd design an email server". Its follow-ups do ask how to store mail as the system grows, handle huge mailing lists, stop spam and survive failures.

So a product round still tests scale and failure. It reaches them through the product's own features, starting from what a user does in the app.

The two rounds share tools but spend their depth in different places. An infrastructure system design round starts from a scale target and goes deep on machines, storage and failure. A product round starts from a user and goes deep on the contract between app and server.

The overlap is large. A product round still expects a sensible server and database, and a good infra answer still names its APIs. The SevyDevy system design interview framework covers the infra-first flow; this guide covers the user-first one.

An everyday picture helps. An infra round is like planning a city's water supply: pipes, pumps, pressure and what happens when a main bursts.

A product round is like designing one railway reservation counter. The passenger is the user, the forms they hand over are the API calls, and the reservation chart is the data model.

Where the picture breaks: a clerk sees each passenger once. An app on a bad network may send the same request twice after a timeout, so every API call must expect repeats.

Because every endpoint and table should trace back to a step a user takes. Journeys also keep the scope honest: in 45 minutes you can design three or four journeys well, not twelve.

Write each journey as actor, trigger, steps and what they see at the end. Say them aloud in about 4 minutes, then ask the interviewer to cut or add one. For event invites, four journeys cover the feature.

• Host creates an event: title, start time, place and who can see it, then invites friends from a contact list.
• Guest replies: opens the invite from a notification, sees the details and taps Going, Maybe or Can't go.
• Anyone invited views the guest list: who was invited and how each replied, newest invites first, loaded one page at a time.
• Host edits the event: changes the time, and guests who replied Going get a notification.

Then name your non-goals, the parts you will not design, such as payments, chat and search. Saying them out loud protects your time and shows judgement.

Ask two product questions that change the design. First, how big can an event get: a dinner for 12 or a college fest with 20,000 invites (both made up)? Second, can guests see each other's replies?

The first answer decides whether the guest list needs paging and whether one counter becomes a hot spot, a single row that too many writes hit at once. The second decides the permission check on every read.

It names each call the app makes, in plain words, before drawing servers. For each call, say who sends it, what it carries, what comes back and what happens on a retry.

API-first means you design the contract before the internals. The contract is the agreement between app and server: paths, fields, errors and status codes, the numbers such as 201 or 412 that say how a request went. Here are the six calls for event invites.

• Create an event: the host's app sends a POST to /events with title, start time, place and visibility. It adds an idempotency key, a random ID made once per tap. The server replies 201 Created with the event's ID.
• Invite guests: a POST to /events/EVENT_ID/invites with a list of user IDs. The server skips anyone already invited, so sending the same list twice changes nothing.
• Reply to an invite: a PUT to /events/EVENT_ID/rsvp with a status of going, maybe or not going. PUT replaces the caller's single reply, so a retry leaves the same state. If the guest then changes their mind, the app cancels or ignores the old call, so a late copy cannot land last.
• Open the event page: a GET to /events/EVENT_ID returns the details, the host's name, the going count and the caller's own reply. One call per screen matters on slow mobile networks.
• Load the guest list: a GET to /events/EVENT_ID/guests with a limit of 20 and an optional status filter. It returns 20 guests plus a next cursor, which the app sends back for the next page.
• Edit the event: a PATCH to /events/EVENT_ID with only the changed fields, plus the version the host last saw. If someone saved first, the server refuses with 412 Precondition Failed.

The reply uses PUT, and create uses POST with a key, for a reason. RFC 9110, the HTTP standard, defines PUT, DELETE and read-only methods such as GET as idempotent. POST is not on that list, so a create needs its own protection.

An Idempotency-Key request header, a named field sent along with the request, is being standardised for exactly this by the IETF, the body that writes internet standards. As of 28 October 2026 it is an Internet-Draft, a working document at revision 08, not yet an RFC. The idea works the same whether you put the key in a header or the body.

Say what the client does too. It shows Going at once and rolls back if the call fails. It keeps the event page cached and reloads it after a 412.

Meta's prep prompt also asks how new features avoid breaking older clients. A safe default is additive change: add optional fields, and never rename or remove a field that shipped apps already read.

REST is the common API style that names resources by path and acts on them with HTTP methods, as above. For deeper REST detail, such as error formats and status codes, the SevyDevy API design interview guide covers the contract on its own. Here the API is one step in a bigger answer.

Give one table per thing the journeys create, with a primary key that enforces the rule you care about. Then point at which journey reads or writes each table.

Pause and predict: why is each reply its own row keyed on event and guest, rather than a list of guest IDs stored inside the event row? Think about the double tap from the opening.

The key does the work. With event_id plus user_id as the primary key, the database itself refuses a second reply row for the same guest.

An upsert then changes the reply in place. An upsert is an insert that turns into an update when the row already exists. PostgreSQL is a widely used open-source database. Its version 18 docs say the ON CONFLICT DO UPDATE form guarantees an atomic insert-or-update outcome: one of the two happens, even under high concurrency.

The going_count column is a denormalised counter: a copy of a number you could compute, stored so the event page does not count thousands of rows on every view. Change it inside the same transaction as the reply.

A transaction is a group of database writes that all succeed or all fail together. Change the counter by the change in status, not by one per request, or retries will inflate it.

Lock the event row first, before reading the old reply. A row lock makes other transactions wait for that row, so two copies of the same request take turns. Without that lock, a retry that overlaps the original can still count the guest twice.

The visibility column decides who may read the event, and every read checks it. The version column is a number that goes up on every edit; the edit call uses it to catch clashing saves.

Pick the parts where a careless design shows users wrong answers, and prove yours does not. For event invites that means double taps, a guest list that shifts while someone scrolls, and two hosts editing at once.

We built a naive and a fixed version of each in SQLite and ran them. The naive version is shown because it is wrong, and the table says how.

What just happened? Each naive design looked fine with one user on a good network. Each failed only when the real world arrived: a timeout, a new invite or a second editor.

Retries: make every write safe to repeat

RFC 9110 explains why idempotency matters. An idempotent request "can be repeated automatically" if the connection fails before the client reads the response.

So make the reply a PUT and make create safe with a stored key. Put a unique constraint on the key, a rule that no two rows may share it, so two racing retries cannot both insert. In our run the second insert was rejected.

Queue the host's notification only when the status actually changed. A retry changes nothing, so it notifies nobody.

Two copies of one request can also overlap: the original is still running when the retry arrives. In our PostgreSQL run, both read no reply yet and both added 1. Locking the event row first fixed it.

Paging: use a cursor for lists that change

OFFSET paging asks for rows 11 to 20 of whatever the list looks like now. If a new invite lands at the top, every row shifts down one, and the reader sees one guest twice.

A cursor says "start after this guest" instead, so new rows at the top cannot shift the next page. The PostgreSQL 18 docs add a cost point: rows skipped by OFFSET "still have to be computed inside the server".

Order by a unique pair, here created_at plus user_id. The same docs warn that without a unique order, different pages give inconsistent results.

Edits: send the version you saw

This is optimistic concurrency: let edits run, and reject one only if the data changed since it was read. In HTTP the app sends the version in an If-Match header. Its value is the ETag, a version tag the server returned earlier.

RFC 9110 says If-Match is most often used to prevent the "lost update" problem. If the tag no longer matches, the server must not apply the change, and it may reply 412 Precondition Failed.

Choosing PATCH over PUT does not prevent this by itself. Any write without a version check can overwrite a newer save, which is exactly what our naive run showed.

Here is the reply journey with those rules applied. A message queue is a list of jobs that a background worker picks up later, so slow work does not delay the user.

One gap remains in this picture. If the server crashes after the commit but before step 5, the notification is lost. Writing the job to an outbox table inside the same transaction, for a worker to send later, closes that gap.

Where scale enters, and only there

Scale questions come after correctness, and only for the busy paths the journeys reveal. Here that is the made-up college fest with 20,000 invites, where replies spike after the announcement.

Every reply that changes status updates the same counter row. In PostgreSQL 18, every UPDATE takes a row lock that conflicts with the same lock from another transaction. So concurrent replies to one huge event wait in line on that row.

Offer two options and pick one. Split the counter into several rows and add them up on read, which the SevyDevy sharded counters guide explains. Or count replies in a background job and show a slightly late number.

For a fest page, a count a few seconds late is probably acceptable; state that as an assumption. Then the background job is the simpler choice. For a dinner of 12, keep the plain counter and say why.

They score how you reach a design as much as the design itself. Meta's virtual interviews post says what's most important is how candidates "talk about their ideas, think about different options" and solve problems. Neither Meta page we cite publishes a numeric rubric. Meta's prep post does name behaviours, and the table maps them to a product round, with our advice marked.

Five mistakes cost the most in product rounds, in our view.

• Opening with a scale estimate the question did not ask for. A dinner-invite feature does not need a requests-per-second figure in minute two.
• Naming endpoints after verbs, such as /createEvent, instead of a resource and a method.
• Forgetting the second actor. Hosts and guests see different screens and have different permissions.
• Leaving privacy unsaid. State who can see the guest list, and check it on every read.
• Treating a stored count as free. A count that drifts from the rows is a bug users notice.

Use about 40 minutes for the design and keep 5 for your questions. Meta's prep post says the interviewer "will typically save the last five minutes" for them. The split below is our plan, not a company rule.

1. 1

   Minutes 0 to 4: clarify

   Ask who the users are, the biggest event size, who can see replies and which platforms matter. Write the answers in a corner of the board.

2. 2

   Minutes 4 to 9: journeys and non-goals

   Write three or four journeys as actor, trigger, steps and result. Name what you will not design, and check the interviewer agrees.

3. 3

   Minutes 9 to 17: API calls

   Walk each journey and name its calls: method, path, key fields, response and status codes. Say what each call does on a retry.

4. 4

   Minutes 17 to 24: data model

   Draw the tables with their primary keys. Point at the key that enforces each rule, such as one reply per guest.

5. 5

   Minutes 24 to 33: deep dive

   Pick the riskiest part: retries, a list that shifts while paging, or clashing edits. Show the naive version, say why it fails, then fix it.

6. 6

   Minutes 33 to 38: scale and failure

   Find the busy path, such as one counter row for a huge event. Offer two options and pick one with a reason.

7. 7

   Minutes 38 to 40: recap

   Trace one journey through its calls and rows in a minute. Name one thing you would build next with more time.

8. 8

   Minutes 40 to 45: your questions

   Ask about the team's product and how they ship. Do not spend this time redesigning.

If the interviewer steers you elsewhere, follow them. The plan is a default for when nobody steers, not a script to defend.

Bring journey framing into an infra round in about three minutes, then switch to scale. It shows product sense without ignoring what that round scores.

1. 1

   Name two journeys

   One sentence each, such as a guest replies and a host edits. They tell the interviewer what the system is for.

2. 2

   Turn them into calls

   Name the two or three endpoints those journeys need, with their methods and what a retry does.

3. 3

   Show the key tables

   Two or three tables with primary keys. This is where correctness lives.

4. 4

   Switch to scale

   Now estimate load, pick storage and add caches or queues where the journeys say traffic is heavy.

5. 5

   Close the loop

   Trace one journey through the final design to show nothing got lost on the way.

Practise on apps you already use, and write the answer as journeys, calls and tables in 40 minutes. Then score yourself against the signals table, one row at a time.

• Split a restaurant bill among friends and send each a UPI payment request. UPI is India's real-time bank-to-bank payment system.
• Save articles to a reading list and share the list with a friend.
• Post comments and replies on a short video, newest first, with likes.
• Let a college club run a poll that each member can vote in once.

For each, look for the double tap, the shifting list and the clashing edit. When one does not apply, say why in a sentence.