Mastercard · Primly Community

Mastercard senior / L5 system design interview, what to expect (went through it April 2026)

hardware_hugo · 4 replies

Just finished the loop for a Senior SWE role at Mastercard (payments platform team, NYC office). Wanted to write this up while it's fresh because I couldn't find much detail when I was prepping.

The system design round was one of two technical interviews in the onsite. My interviewer was a principal-level engineer on the transaction processing side. He gave me a vague prompt: design a payment notification system that handles real-time alerts for 500 million cards. Classic Mastercard-flavored prompt.

What he actually cared about: Throughput and latency tradeoffs. He kept pushing: what happens at peak holiday traffic? How does your queue handle backpressure? Idempotency. I mentioned it early and he immediately wanted to dig in. Expected at a payments company but he was unusually thorough about it. Failure modes. Not just "add a retry" but: what does partial failure look like across regions? How do you know a notification was delivered vs just sent? Data consistency model. He asked whether I'd choose eventual or strong consistency for the notification state store and why.

What didn't matter much: Specific AWS service names. I was drawing on Kafka/Kinesis comparisons and he wasn't attached to either. He cared about the concept, not the vendor.

The round was 60 minutes. First 10 were clarifying questions (I asked about notification channels: push, SMS, email), then ~30 min designing on the shared whiteboard doc, then he poked at my design for 15 min, last 5 he explained how they actually do it at Mastercard. That last part was actually useful and felt like a good sign.

Overall the system design bar felt like a solid senior bar, not Staff. Less ambiguous than a FAANG design prompt, more grounded in fintech constraints. If you've done payments infra at all, you'll feel at home. If not, brush up on at-least-once vs exactly-once delivery semantics before you go in.

Got the offer about 10 days later. Happy to answer questions.

4 replies

sre_sol

The idempotency deep-dive tracks. When I interviewed there in 2024 the same pattern came up. They really care about what happens when a notification fires twice. I had a 10-minute tangent on deduplication keys. Did you end up getting asked about database choice for the notification log or did they just assume Postgres?

backend_bekah

He asked what I'd use and I said "probably Postgres with a unique constraint on the idempotency key" and he seemed fine with that. Then I mentioned maybe Cassandra for write-heavy scale and he said that's actually closer to what they use internally. So having a reason for your choice matters more than the specific answer.

market_realist

Did they ask about the CAP theorem explicitly or just implicitly through the consistency questions? I've been prepping that distinction for fintech interviews and wondering how deep they actually go.

backend_bekah

Implicitly. He didn't say "CAP theorem" once but every question was essentially testing whether I understood the tradeoff. I wouldn't memorize the theorem definition; instead know what you'd actually sacrifice in a payment notification context and why.