What to Expect in the Paytm System Design Interview

Expect a design discussion shaped by Paytm's own payment products. Candidates at senior levels report a dedicated design round of about 45 to 60 minutes, and other reports describe the design questions asked inside a technical or managerial round. Reported questions include a system that supports several wallet types with a linked bank account, a hotel booking system, an in-memory SQL database, and a schema for an expense splitting application. Interviewers ask detailed questions about idempotency, locking, and transaction isolation, which are the daily problems of a payments company.

Is There a Machine Coding Round?

A machine coding round is a session of about 90 to 120 minutes where you build a small working program and are graded on code that runs. Candidates for backend roles at Paytm do not report a separate round of that kind, but rather design questions asked as a discussion inside a technical or managerial round, with some class and interface design on a shared editor.

Some front end candidates do report a build task on an online assessment platform, such as a simple game written in HTML, CSS, and plain JavaScript inside about an hour. The difference between the two round types is explained in system design versus low level design.

The Question Types

Wallets and payment flows. Candidates report a question about a system with several wallet types and a bank account linked to the user. Required operations include adding money, transferring money, checking the balance, and listing transaction history, while the difficulty comes from double spending, retries, and reconciliation with the bank.

Low level design. Reported questions include an in-memory SQL database, a hotel booking system, and a schema for splitting expenses between friends, all of which grade class structure and ease of extension rather than throughput. The common question shapes are listed in what a low level design interview is.

Service design from your own domain. One candidate reports a question about consuming Paytm APIs to give cashback, and another about designing campaign APIs for an online food delivery application. Interviewers often pick a system close to your resume, and then add a new requirement partway through the discussion.

Data modeling and query performance. Candidates report schema design questions followed by query tuning in the same round, so expect questions on indexes, isolation levels, and optimistic versus pessimistic locking.

A Walkthrough: A Wallet and Payment System

Here is a high level plan for the wallet question, which is the design problem Paytm candidates report most often.

1. Requirements (about 5 minutes). Users hold several instrument types, such as a wallet and a linked bank account, and the operations are add money, pay a merchant, transfer to another user, and view history. Correctness matters more than latency, so state that priority before you design anything.

2. The ledger. Store money as a double entry ledger, where every transfer writes a debit row and a credit row, and never store a balance as a single editable number that one request can overwrite. Compute balances from the ledger rows, and then cache the result.

3. Idempotency. Every payment request includes a key that the client generates, and the service stores that key together with the result, so that a retried request returns the stored result instead of moving money twice.

4. Concurrency. Two payments from the same account can run at the same moment, so use a row lock or a conditional update on the account version to prevent a lost update. Explain why you chose the pessimistic or the optimistic approach.

5. External systems. Calls to a bank or to the UPI network fail or time out regularly, so record the request before you call, and reconcile the state later with a scheduled job. A timeout means the result is unknown, so never assume that the transfer failed.

6. Settlement and scale. Merchants are paid in batches on a fixed schedule, not on every transaction, and the scale work is to partition the ledger by account, queue write spikes, and keep a separate read path for history.

What the Interviewer Grades

State the requirements before you draw anything, because the interviewer grades the order of your reasoning, and name the failure cases early, since a payments interviewer waits for them. Explain each trade-off out loud, with the reason for your choice. Candidates report interviewers who add a requirement partway through, so keep the design easy to extend, and remember that clear data models score better than long lists of components.

Common Mistakes in This Round

• Storing a balance as one number. Without a ledger you cannot audit or reconcile a disputed transaction.
• No idempotency plan. Retries are normal in payments, and a design without keys pays the same merchant twice.
• Treating a timeout as a failure. An unknown result needs reconciliation, not a silent retry of the payment.
• Skipping the schema. One reported candidate received direct feedback on weak database design, so write out the tables and the keys.
• Designing for scale before correctness. Sharding matters later, and a correct ledger matters first.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and replication, which every payment design uses.
• Practice class design. Grokking the Object Oriented Design Interview prepares the booking and splitting questions.
• Rehearse the walkthrough. Present the six steps above out loud in under 40 minutes, with a timer running.
• See the full loop. The design round is one part of the Paytm interview process, so read it with the motivation question and the reported waits between rounds.