An Interview with a Netflix engineer

Watch someone solve the payment pipeline design problem in an interview with a Netflix engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
Payment Pipeline Design

Interview question
We have a group of interconnected services in our ecosystem.

As owner of system B, you need some data from system A and massage and process that data along with other user inputs to your system to generate an output that you need to pass down to system C.

We have system A, as a rights system which stores information about when a movie can be streamed in some country and as owner of system B which is a financial accounting system, you need to combine the data from rights with user input about the total amount that needs to be paid, over the given time period, and the frequency of payment, to produce accurate entries which need to be sent to a payment system C.

Interview Feedback

Feedback about Eponymous Pigeon (the interviewee)

Advance this person to the next round?
No

How were their technical skills?
3/4

How was their problem solving ability?
3/4

What about their communication ability?
4/4

Strengths & what went well
Overall great interview, I would rate it a 3 / 4 overall in actual grading.
Great structure going through the interview, you asked clarifying questions, wrote out the different systems we would need to think about, discussed functional and non-functional requirements, and started to discuss scale. You also correctly mentioned that we were dealing with highly coupled information so a SQL database would work well.

Areas for improvement
Different design solutions (Sync/Async, Push vs. Pull)
As you continue to do more practice interviews you will see different ways to design systems. In our case an event-driven approach would have been a good solution to consider and weigh the pros and cons. For the future try to discuss 2 popular methods of solving / implementing your solution, and discuss the trade offs with the interviewer. This will show them that you are aware of the solutions, and the interviewer can help guide you in the direction they may want the conversation to go.

Whiteboarding
The whiteboarding went well but you initially wrote a Job Queue, that when we went back to it you had forgotten what you originally wanted to do with it. This happened in my opinion because you didn’t know exactly how you wanted the entire design to look like before you started whiteboarding. In our case we were modeling, doing the API, and whiteboarding simultaneously because you may not have had the full picture (which is okay), but if you can have the entire idea of what you want to do before you start to draw it will be helpful.

Interview Transcript

Cool Koala: All right, so I've gone ahead and pasted some text into the box. We free to take your time to read it. Take as much solid time as you need, and then we'll work through it together.

Eponymous Pigeon: Yeah, sounds good. I'll just read it out loud. How I like to process it. So we have a group of interconnected services in our ecosystem. As owner of system B, you need some data from system A message and process that data along with other user inputs to your system to generate an output that you need to pass down to system C. Okay.

Cool Koala: Okay.

Eponymous Pigeon: Example we have System A is the right system which stores information about when a movie can be streamed in some country. And as an owner of system B, which is a financial accounting system, you need to combine the data from rights with user input about the total amount that needs to be paid over the given time period and the frequency of payment to produce accurate entries which need to be sent to the payment. System C is the example.

Cool Koala: Yeah, so that would be like, the generic, like, prompt of what we're about to get into. And then I would say the example maybe I should remove that word is like the. Our example that we'll work with.

Eponymous Pigeon: Gotcha.

Cool Koala: And it gives like a description of like what A, B and C actually are. Okay.

Eponymous Pigeon: So system A is a write system source information about when a movie can be streamed. Okay. Because there's like different movies that can be streamed depending on which country you're in. And in system B, financial accounting, the data from rights with user input. Because you only get paid for kind of like the quality or the content that you're delivering. Like an accounting sense.

Cool Koala: Yes, yeah. And if you have like particular questions. But both of those. What you just said sounds really right. And I can give some more color once you're done reading.

Eponymous Pigeon: Yeah, yeah, no, I, I got through it also. Any more information be good. I think I kind of get the high level, like we're trying to figure out how much revenue to recognize across countries when there's different content that's been streamed in those different countries.

Cool Koala: Yeah, 100%. And so to give you an example, starting with system a, so you're 100% right. So rights says like when a movie can be streamed in some country. So for example, movie 1, 2, 3 can be streamed in the US for all of 2025. Like those are the rights we have for that movie.

Eponymous Pigeon: Okay.

Cool Koala: As an example, I take some notes.

Eponymous Pigeon: So a riot is like a period of time in which a title can be streamed or watched in a country then?

Cool Koala: Yes, that is definitely correct. Okay.

Eponymous Pigeon: Okay.

Cool Koala: Yeah. And so for system B, I would agree. So it says which financial accounting system user input about the total amount that needs to be paid over a given time period. So you could say a user input or an example of the information could be like we need to pay like a million dollars because we have the rights to this for that period of time. We need to pay a million dollars over that one year period. And that could be split into maybe like quarterly, maybe it's monthly. But yeah, that is our kind of like our fee for having those rights.

Eponymous Pigeon: Oh yeah. Okay. So it's for content that like you don't necessarily produce and have the rights to.

Cool Koala: Yeah, that is a good. Definitely this would cover that scenario. Yeah. Okay.

Eponymous Pigeon: And like it's. The rights that we're paying are tied to how much the users paid. This part I'm kind of confused about what. I'll just kind of go in the same bucket.

Cool Koala: Good question. So in this scenario, it wouldn't be related. The fee might come from maybe like the studio or like whoever we get the movie from that says like hey, like, if Netflix wants like this movie on netflix.com, like, no matter, like, how much you're charging for subscriptions, like, I'm going to, like, Sony Pictures is going to give it to Netflix for like a million dollars. Like, that's just like, how much you have to pay. And it's like up to Netflix to decide if it's worth it for them. So you don't have to worry about the, like, how much people are paying for Netflix. But you could assume that, like, that's like just user input. So, like, all that, all that, like, business logic is like, outside of the scope of this exercise.

Eponymous Pigeon: The business logic of how much users are paying are outside of this.

Cool Koala: Yeah. So you could just assume, like, they come into the system, like, with the, like the numbers they, they know they need to put into the system.

Eponymous Pigeon: Oh, so this is user, not like Netflix. Oh, but like, okay, so an admin to the system or something like that.

Cool Koala: Yeah, sorry, that is a good clarifying question. So this would be like Netflix, like financial accountants, like employees of Netflix. Yeah, so definitely good question. Like, who is using the system B?

Eponymous Pigeon: Yeah, like how Netflix accounting professionals for system B anyway. Right?

Cool Koala: Yeah, 100%.

Eponymous Pigeon: Okay. System B, financial accounting. And you combine the data from rights with user input about the total amount that user paid. Okay. All right, so that's Okay. I was confused a bit about which users. That makes sense. So the user B says, we have title A and that costs a million dollars over this one year period. And system A is like, this is how much it was streamed in certain countries. And then system C is, over the given time, variant the frequency of payment to produce accurate entries which need to be sent to a payment system C. So there's like some sort of accounting recognizing revenue that needs to be sent to system C based on what was actually streamed and what was paid.

Cool Koala: Yes. Yeah. And so for. And to make it, like, simpler, we don't have to keep track of, like, streams, but system A just says, like, we have the, the rights to this movie for 2025 in the US so even if no one watches it, we still need to pay this to make it.

Eponymous Pigeon: All right, so if I start. Thanks for filling all that in. So if I, if I start with some functional requirements here. We want to make sure we're paying the, I guess call them royalty fees or titles we don't own and make sure we're doing it accurately. Which basically means like, producing accurate entries for system C. Does that sound about right or am I kind of.

Cool Koala: Yes. Okay. Yeah. No, this, this sounds right.

Eponymous Pigeon: And like before I forget, this is sounding very like if we kind of hop to non functional requirements, like we really probably want to favor consistency over.

Cool Koala: Availability.

Eponymous Pigeon: And that's a good trade off. It's like anytime you do a financial systems it's kind of where my brain goes to because I mean, I guess this isn't like time sense but we want to make sure we're not, we're not like not duplicating entries or like, you know, I'm imagining there's things about eventual consistency that might mess things up that we kind of want probably some make sure we're sending the right entries and getting the right information.

Cool Koala: Yeah, definitely I agree with you. Like when it comes to financial systems, definitely like consistency over availability is a good trade off. Yeah. If that comes up, this is definitely like where I definitely agree with that.

Eponymous Pigeon: And then. Yeah, and then we talked about in the problem statement for system B it needs to accept input, right?

Cool Koala: Yes, good, good observation and noting that down. But yet there will be some input.

Eponymous Pigeon: Little amount that needs to be paid.

Cool Koala: Yeah.

Eponymous Pigeon: So like what's different about the amount that needs to be paid versus like the royalty fees?

Cool Koala: So you could say they're the same in this case. So I would say like your first bullet is like summarizing like the entirety of the system. But system B specifically, like it accepts the input and you could. Total amount would. Yeah, same as royalty fee. Total amount would be like the royalty fee.

Eponymous Pigeon: Okay, so then system A is really just about feeding the information that produces combined with the royalty fees produces the accurate accounting entries.

Cool Koala: Yeah. Yes. It kind of gives us a guide of like what like what movies need to like. Yeah, like if, if there's no record in system A, like the users of system B don't really need to do anything. But if there is a record in system A, then they know that they have some accounting to do for it. Okay.

Eponymous Pigeon: Like they're accounting specifically per movie.

Cool Koala: Yes. Which sounds like a lot. Yeah, sometimes it can be but in this scenario that is true per movie. Okay. Okay. All right. So.

Eponymous Pigeon: I think I get it on high level functional requirements. Non functional. I think the main thing I want to say is like we really want consistency. We want obviously needs to be very secure, secure payments and stuff. Security in general kind of a given. But I'll just note it. But if that, if it's okay with you, I think I can move on to like if this looks like I got it on a high level I can kind of move on to defining kind of the scale of this and like some numbers. So if we have, let's see, trying to get a number, how many titles Netflix has and like how many. So we have like X amount of titles, X amount of countries Netflix is in. And then we need kind of like how often we're processing this, like doing, doing this transaction. So if I just kind of do. I don't even, I guess, just pull number.

Cool Koala: Yes, that's a. Yeah, that's a great guess.

Eponymous Pigeon: Really?

Cool Koala: Oh, oh, yeah. It's like much less than that. But. But I actually. That's a good question. But that's a great number for us to like, work with.

Eponymous Pigeon: Yeah.

Cool Koala: Okay.

Eponymous Pigeon: Because we want to plan for growing anyway, so you can trade this too much.

Cool Koala: Yeah.

Eponymous Pigeon: And then I know Netflix operates globally, so I'll just say 50 countries for now. I'm not sure it matters too much, but it does kind of give us some complexity and then like, are we, are we doing this? Like, we're doing this like on a monthly basis, kind of like a, like a settling for the month?

Cool Koala: Yeah. So definitely we would want to, like, there are some like, monthly aspects. And so. And so when you say doing this, what do you mean?

Eponymous Pigeon: Yeah, that's a good point.

Cool Koala: Yeah.

Eponymous Pigeon: I mean like, how often are these accounting professionals having to go and like, are these entries created in real, like as days go by or is it. Is there like events that they go in and say, okay, now we need to provide all the entries and like close the books for like certain day? Or is it just day by day when you have the most up to date, accurate entries?

Cool Koala: Yeah, that is a good question. So I would say there are. It depends how you want to like, architect the system in terms of how like system A talks to system B. But we could go with the like, daily or like, monthly approach to like, I'd say on a monthly basis. On a monthly basis, they are making sure everything, like at the end of the month, they're making sure that like, they've like, for all the latest System A record, they've. They've done the user input in System B.

Eponymous Pigeon: Okay.

Cool Koala: Okay.

Eponymous Pigeon: Yeah, I'm just, I'm just thinking about when, like, for, for System A, then is it. I'm just thinking about how it's going to like how they're expecting the data to come. Like, like they watched this title, this title was watched for X amount of minutes or over a time period.

Cool Koala: Yeah. So great question. Yeah. So this is definitely one of the first things we could think about is like, how would you like architect, like the communication between like all three systems. But specifically since we're talking about system A, that information could look like it can be as simple as kind of like your, maybe your identifier for the, for the title. Your like what country or countries it's available to be viewed in. And maybe like that, that, that period for which it's like valid which is like all of 2025 or like maybe it's 2point 2025, 2026. So we don't need like minutes or like watch time, right?

Eponymous Pigeon: Yeah, you already, you already kind of explained that it's not about who watched it, it's about. Yeah, just like, like how long they have, like how much it costs and for how long. I call it like royalty fee or not royalty fee because that's what comes in for system B from input. It's about the rights to a country.

Cool Koala: Yeah.

Eponymous Pigeon: I can come back.

Cool Koala: Yeah, yeah, you can come back and see if you need to add anything else. But that looks good. Like title info and the rights, which is like we know to be like country and.

Eponymous Pigeon: Yeah, and system B would have like the inputs from the users, the royalty fee for the title and then like the time period.

Cool Koala: Yeah. And this time period would just be the how, how many payments we need to make or like how long are we like paying this fee for. And it doesn't necessarily have to match how long Netflix has the rights to the movie. Don't need to be like the same time period we need to pay. But that's a very small detail. But in this case, time period looks good. And this would be like a million over one year. Maybe it's a million over two, two months. Kind of like payment schedule.

Eponymous Pigeon: Okay, so like system A would say for title A, these countries have the rights and then system B says the royalty fee for that title, which I guess we need title info of some sort in here to match up.

Cool Koala: Nice. Yeah, definitely a good catch.

Eponymous Pigeon: It's going to be this like a X amount of million or whatever it is for this time period. And then, then system B take like system B provides. I guess what, I guess I gotta think about what is the input system C is expecting in terms of accurate.

Cool Koala: Yeah, 100%. We didn't talk too much about it yet, but you could think of system C as like this is the system that takes care of like money out the door. So we are doing some accounting but sometimes that we've said fee. So like, you know, fee means someone else is getting paid. So system C deals with like money out the door. And we don't have to think too much of how that system works, but definitely ask a good question of like what are we sending them? Like what do they expect? So I guess you could think of like what would they need to like send money out the door?

Eponymous Pigeon: Okay. What would they need to send money out the door? They need to know. I mean we need to look at the royalty fee and we need to see like we'll need to store how much we've already paid over a time period. Like I guess we'd have to decide. System B would have to decide how much have we already paid? How much do we owe? It'll have to know information about I guess the royalty fee is probably maybe different per country with the rights.

Cool Koala: Yeah, probably. You make a good point. Yeah, System B would take care of like figuring out how much is due when. But we could make it simple and say like system B, you know, we figures all that we don't have to think too much about like the like the application logic.

Eponymous Pigeon: But okay, that's what's kind of like trying to think of what the logic would be inside. So I know what data it actually needs to hand over to system C. But if we just say system C is saying like you get the amount and then like the whoever's accepting like the acceptor of the money.

Cool Koala: Yeah, I know that's. Yeah. Who's like who gets the money. Definitely a good receiver.

Cool Koala: And, and we could assume that's like tied to like the movie somehow some way. But this looks good. I think that's definitely the two most important pieces of info system C would need. And we don't have to think about the outputs of system C. We just like know it's like money out the door. So they will do what they do. But our job is done if we can get them that information. Okay. Okay. And.

Eponymous Pigeon: System. Okay.

Cool Koala: Any questions there?

Eponymous Pigeon: No, I think there's just some complex like I think the tricky part is like the rights and like we'll have to. The titles can change like once you have the rights, can they change whichever country you have changed like mid contracts or. I guess that's what they're concerned about when they enter the royalty fee in. So we don't necessarily have to worry about that.

Cool Koala: Yeah, no, that definitely is a good question. And it probably can happen. We could keep it simple and like for now assume like it doesn't change after like the first time we like get that information. But definitely a good, a good point.

Eponymous Pigeon: So let me, before I go draw boxes, I wanted to just lay down some simple APIs.

Cool Koala: And you could think about. You're definitely about to get into it. But yeah, you can be. Now you can really get into how you want. Like you're, you're kind of in control of like how system A talks to system B and like of course how B talks to C. So. Yeah, so feel free to do that now.

Eponymous Pigeon: Yeah, yeah, yeah. So if it's on a monthly basis, like the first thing I'm thinking of, I guess I can just high level draw something here. If we kind of assume there's a schedule and in that schedule we say we need to make sure we're like kicked off and sharing. System B has the info it will need for the accounting professionals. Professionals. Accountants, I guess you say, or the Netflix professionals. The Sysma would be the Sysma service, I should call it. I toggle back, I guess. I don't where this information is coming from. Are we defining people inputting this information in or is it like already existing somewhere in the ecosystem?

Cool Koala: Yeah, you could say like it already exists in system A. Like from A. For your understanding, like there's probably other Netflix users, employees who like put that information into system A, but for us it's like already there.

Eponymous Pigeon: Okay, so like somewhere they're storing the movie rights, which I guess probably if I think about like what a write is and like title info, it probably has like title ID and other metadata and then the rights are like a list of like countries or like a country that has the right to it or like a geographic location.

Cool Koala: Yeah, definitely, like, oh yeah, sounds good. Yeah, please keep going. Sorry.

Eponymous Pigeon: Well, yeah, I'm just thinking about like this feels kind of relational in a way and like we probably just go with SQL right now since there's.

Cool Koala: A.

Eponymous Pigeon: Lot of relationships in those defined between them. And so what I'm thinking of right now, just real simple is like schedule kicks off a job for system A to get job queue. And like system A knows, sees that we have a job to run and then it talks to the data here, the movie rights data. And besides like we have, I mean it needs to know, I guess like the. I'm really struggling with the difference.

Cool Koala: No worries.

Eponymous Pigeon: Like how the system be like put out system B here, right? And like the start of our system is there's a client somewhere that the user's connecting to and saying like, okay, we need to settle up our accounts. And it says okay, are There like get endpoints. But they're saying what are all the different jobs that are like literally different data we're missing or need to pay?

Cool Koala: Like. Yeah, that's a good question. Do you have like a preference on like what would make it easier either? Like, there's probably pros and cons of different solutions, but do you have a preference on like what would make it easier for the client or maybe like easier for the system? Because we know like we know that like let's assume like every piece of information in system A, like the clients or the, the users of system B, like wanna, you know, attach those royalty fees. So if like that's the goal, I guess, like do you have any. I would love to hear you like just give any like opinions of like, which like how would they do their best? How could we design a system so that they could do that?

Eponymous Pigeon: Yes. Yeah, thanks, that helps. Yeah, like you would say like if I were the user there, I would say what are all of our rights that we have that we don't already have royalty fees for covered? And for the ones that we don't have royalty fees covered, I want to know those so I can go put those in to make sure we're covered to pay money out the door to system C.

Cool Koala: Cool. Okay, so does it sound. Yeah, that makes sense. So it's kind of like kind of like maybe a fetching from system B side. So like system B checks system A for rights that we don't already have a royalty fee for. Is that kind of what I heard?

Eponymous Pigeon: Yes. Yeah, exactly. So this would have like a get rights, like missing rights, but it accept like the rights where. Let me just write down what I just said. So system B we'll like to start with. We'll query system A about which I guess it.

Cool Koala: Yeah, we said which writes which rights we. Which rights system B doesn't yet have a royalty fee for is what we said. And so with this like I see your question, you're like, oh, like should. Should system A have the endpoint that says like missing rights. But you know, only system B will have that info. So it could be more so like a, you know, system B keeps track of course of like the royalty fees it has. So it's more maybe fetching oh yeah. So this does oppose a good question like how does it get, how does it distinguish like it doesn't know what it doesn't know. So it's, it's like. So this is a good question. So we could either, if we, if we got all the rights from system A, System B would be able to, you know, pull out only process ones it hasn't seen before. Is one way to do is getting a lot of information. But that is one way to do it. And we did say it's monthly, so maybe it's not a bad thing. We haven't talked about like how much data exists like on a monthly basis. So maybe it's not a lot. But I think that's one way to get over our little hump here.

Eponymous Pigeon: Okay. Yeah. So like if we tie some date information here like right start. I guess it would be like to the right with like date start, date.

Cool Koala: End, maybe even like a created or. I don't know if that would help you too.

Eponymous Pigeon: Yeah, it would. Yeah. But like I, and I guess we can say this right will have an ID of some sort obviously so we can track like which ones we've processed by system B already. But it's going to be like. Yeah, like I said we could start with a very simple use case and optimize from there where it just pulls everything since a certain date and goes through that.

Cool Koala: Yeah. Because then we, we can, you know, kind of like have like a moving window and we'll try to make sure we haven't missed anything. But yeah, we could say give me the stuff in the last week and then tomorrow it'll get everything except that like seventh day.

Eponymous Pigeon: Yeah. So there's going to be like a get endpoint on system A and we say here's a date range that I want to know all the rights for and that kind of gives back the rights for each title for the whole date range. Cool. And like if we wanted to work better with scale, maybe we could have that create like a snapshot somewhere and that system you can go look at and consume but we can just assume it's going to come through HTTP right now. So user passes that information and I guess they're working with system B but they say like, okay we want to settle and then we move on.

Cool Koala: Sounds good!