We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

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 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?

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. You then went on to discuss APIs and started to to whiteboard. The white boarding showed that you could design a high level system. We also discussed Observability (logging and tracing) as well as different Reconciliations you would do with the Ledger system if we wanted to make sure data between Systems B & C were in sync. Overall good job, I could tell you were familiar with the broad concepts and as you continue to do more mock interviews you will continue to improve. 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. Examples of this would be SQL/NoSQL, Sync (fetching everything) vs. Async ( eventing or polling) 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. This is similar to a coding interview where you would discuss your solution before you start to write it out. Open Notes If you have an area of expertise feel free to expand on that area if it comes up in an interview. Example: you’re great at networking, or databases. When that comes up feel free to discuss it at length to show the interviewer you are experience in that.

Feedback about Cool Koala (the interviewer)

Would you want to work with this person?

Yes

How excited would you be to work with them?

4/4

How good were the questions?

3/4

How helpful was your interviewer in guiding you to the solution(s)?

4/4

I think the question could be a little clearer by removing the first sentence and the “example” part. Otherwise, i found it to be very valuable. The question definitely threw me at first. It was really good practice.

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 a payment. System C is the example. Like, are we saying this problem description? It's, like, pretty generic.

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, 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 a 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.

Eponymous Pigeon: That's probably a better term for that. But whoever's getting the money.

Cool Koala: Yeah, definitely. Perfect. 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? Every piece of. Every piece of information in system A they want to attach a royalty fee to. So like system B wants to know like of every single right piece of information System A. So we don't have to decide yet, but curious your thoughts of like how might you 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 we're going to settle it for, you know, month of January and system B queries give me all the rights for. I don't know what I was thinking with the job key stuff.

Cool Koala: Now.

Eponymous Pigeon: I'll just put that off to here. Give me all the rights between that tame range. This system A service hands it back.

Cool Koala: And.

Eponymous Pigeon: System B is going to do its logic of, I guess.

Cool Koala: Yeah, kind of like figuring out what it hasn't processed. I guess maybe the first time it hasn't processed anything. Maybe. Ideally. But let's say it's processed some stuff already. It kind of like, you know, takes out from that payload like what it's already processed and then it starts to like, I guess get the ones it needs to take action on.

Eponymous Pigeon: Yeah, yeah. Like it's going to figure out which rights it hasn't already processed after it gets it. I guess step one is it's going.

Cool Koala: To.

Eponymous Pigeon: Get the rights for the date range.

Cool Koala: Cool.

Eponymous Pigeon: Figure out which rights hasn't already process. There's like logic, math logic to convert it to the actual payment and then it's going to send like a payment job to a payment queue for system C to consume.

Cool Koala: Got it. Cool. And Ollie.

Eponymous Pigeon: And oh, disappeared. And then so like a lot of what I've put there, a lot of failure points and we're like pulling in a lot of data. So it's like it wouldn't work at large scale very well.

Cool Koala: Here.

Eponymous Pigeon: It's because like what, like I said, what would be really like the, the tricky part is figuring out which ones have already been processed and handling it from there. So I think this, the inputs I said would, I said the month, time, time period. But we also, there's like, there's a communication also that I'm missing with. They want to input the royalty fees too, for everything that they've missed.

Cool Koala: Yeah.

Eponymous Pigeon: So if there's like a lot, a lot of titles to do that for, we kind of, at least we need to present that back to them. And so my opinion is like, you want to, you start this flow, you say, like, I want to start a job for like this time period. And then this stores like a, like a job document of some sort. So that then we can say, here's your job document. Right. And then the client says like this, the job document has like all of the different titles or movies that have that like we need information from.

Cool Koala: Right? Yeah.

Eponymous Pigeon: Like we need the fees for these movies and our time periods for that.

Cool Koala: Right?

Eponymous Pigeon: Yeah, for those fees. And then the client will need to come back and say, well, like maybe they'll fill out some of this because it could be a lot of movies.

Cool Koala: Yeah.

Eponymous Pigeon: And so they're only going to store like some, you know, movie, like post some movie fee information. And then we come in and we update this. And then there would be one last call to say like, we've got our job all filled out and, like, we want to just finalize payment and go ahead and send it over for payment. And that includes, like, who they're sending it to and when. Something with two and one.

Cool Koala: Nice.

Eponymous Pigeon: Yeah. Cool.

Cool Koala: This makes sense. That looks good. We probably have, like, eight more minutes before we just, like, exchange, like, notes. But yeah, were you gonna jump into something else if not? Like, I have a question.

Eponymous Pigeon: Yeah, sure, go ahead.

Cool Koala: Cool. Yeah, this looks really good. You made a good question about, like, failure points, which is, you know, always good to think about, especially as we, like, get bigger and bigger systems. So this looks good. And we kind of have our A to B and, like, B to C. So for one example of, like, thinking of failure points, like, if. If the system C is, you know, a different system with, like, their own set of engineers, their own sets of users, if users of. So, for example, another scenario, if users of system C suddenly stop seeing information from us, like, how can we figure it out without, like, them telling us? Like, how could we. Like, how could we. And we don't necessarily have to write anything down. We could talk about it or write stuff down. Like, how would we, like, architect the system in a way that it would allow us to figure out, like, where things were going wrong?

Eponymous Pigeon: Yeah, that's a good point. Yeah, we would. We would do a system log of, like, this is the entries that we sent over, and we would store it. Basically, when there's a finalization where we send a payment queue over to the payment queue or resend it, or if it's just straight to their servers, however they want us to send it to them. We'd also want to store, like, store finalized payments that we sent, including all the information, right. Like, the amount and the dates and, like, who sent it, like, the person. So there's some accountability. We can trace it back. But if we're talking, like, system, system wide, we could also have some sort of, like, correlation id.

Cool Koala: Yeah, that sounds like a really helpful.

Eponymous Pigeon: Yeah, because then they might come say, like, we're missing this amount from this date or something going on with, like, a certain id, we can easily find it right away.

Cool Koala: Yeah, the correlation ID definitely makes it, like, a lot quicker to figure out, like, oh, like, what do we have? Like, what don't they have?

Eponymous Pigeon: But, like, over then, over time, like, you might want to settle up amounts too, right?

Cool Koala: Oh, yeah.

Eponymous Pigeon: So you probably would want to have ways to query, like, summing up things for a month or like, sending, like, publishing data, saying, this is what we Sent and then we can settle up that way with folks over system C to make sure they're like everything checks out so we didn't miss anything.

Cool Koala: Yeah, cool. That makes a lot of sense and definitely helpful for like as we grow and like especially the settling up because that's like definitely something like the financial systems like want to do another like on the failure side. So we, consistency is dependent on us, but we are kind of dependent on system A and you know, they can have failures too. What are some things we could think about to like make our system like more resilient? Like right now we go to their system and get it but let's say like their system isn't responding or is having some failures. So like any ideas like how we can recover from failures from like systems we're dependent on or just know that they're happening?

Eponymous Pigeon: Yeah, yeah. Or just know that they're happening. Well we could, if we're only in control of system B, you could set up like the last known states of what we got from system A in terms of like caching data we get from them that I mean it does have a downside of, you know, now we have to kind of maintain two different states and may not be totally worth it since maybe we can just look at the data itself if we're in the same system but maintaining what we last saw from them and then getting alerts wired up to say when they're down and like it probably like when they first query to say that we're going to set up this kind of job process. Since we're favoring consistency, we like want to make sure we're getting the right data. Doing that based on a cache might be problematic.

Cool Koala: Definitely a good trade off. Yeah, it'd be like if we. Yeah. Because if we don't, if we don't have the cash and we can't access this domain like then we have nothing. But if we do have the cache, we have like some data users can use but like it's not the freshest.

Eponymous Pigeon: It might not be the correct thing and if we're sending payments over based on old data.

Cool Koala: It might be wrong. Right. Yeah, so yeah, definitely a good point. And like there would be like trade offs there. No right answer. I was just you know, curious. Wanted to like, you know, get that, get those thoughts like flowing to see like where we ended up. Cool. Let me see if I have any other questions. Oh, I guess only other question the similar to your thought of like kind of like truing up the. Do you know, like how, like, to me, it kind of sounded like we wanted to maybe compare. So going back to system B and system C, we wanted to maybe compare, like, the data we had. The data they had. Do you have any ideas like, how, like, outside of this or, like, how we could do that? Like, if we. If we, you know, had, you know, all the resources possible. What are some ideas, like, how we could, like, compare system B and C that, like, all of our data matched?

Eponymous Pigeon: Yeah. I mean, it would be like.

Cool Koala: It could be like a third party system. Like, it could be, like a. Maybe we have a separate job to, like, do that checking or, like, doesn't have to be, like, in here. It could. You could be, like, creative or just thinking, like, quick, quick way to do it. Like, not quick way to do it. Just curious, like, how we would maybe be, like, all right, I really want to check that, like, system B and system C are, like, caught up to each other.

Eponymous Pigeon: Well, I would say, like, for. We would set up, like, a central sort of ledger system that system B publishes to and system C publishes to. And then when they're different, it kind of alerts somebody to say, hey, for this time period, things aren't matching up. And that would be kind of like an auditing system.

Cool Koala: Cool. Oh, yeah, that definitely makes sense. And it would make it a lot easy. Sorry. It would make it easier to check if we, like, sent them to that same ledger.

Eponymous Pigeon: Yeah, you want to rely on, like, the mechanism rather than people going in and checking of their own accord. Right? Yeah, that's what I would do.

Cool Koala: Cool. Awesome. All right, we can. We'll end here. So mock interview over. I'll go into, like, just discussing now. Cool. Going back to the whiteboard. I'll just go, like, in order of, like, what we did and just, like, talk through each point. Okay. But, yeah, I think. I think you did a good job. This is. This question. I don't know if you're familiar with financial systems. Like, you don't.

Eponymous Pigeon: Yeah.

Cool Koala: So totally understand. Like, they can be like. Like, you know, with these questions, like, you jump into. Sometimes we start designing stuff we haven't done before, which is okay, because, you know, there's no right answer to anything. We just. People, the interviewers always just want to see, like, your thought process. So I could tell that, like, it wasn't. This is. I think the wording might be a little hard here. So I'll try my best in the future to change this. This is a real question, though. So, like, great job. This is in this format. It's Been asked.

Eponymous Pigeon: Okay.

Cool Koala: So yes, I think you did a great job like understanding it. And you asked great questions. Like you were like, oh, like what are rights? Like what is what? What are inputs to system B? So like your first like lines like 10 through like 28. I think you did a good job. You like clarified, you made sure like we were communicating. You didn't just like run off in like your own direction. You asked me like clarifying questions. I gave those. We kind of like work together. Which I like to think is like the whole point of the interview is like collaborate. So you kind of talked about the users which is a good find. Like you thought they could be like Netflix users. But we realized it's like business users. You're the domain objects, functional, non functional requirements. I think those are like all great. I agree. Like finance consistency, like over availability. Because we're not designing like Instagram. This is more like want the financial numbers to be right. Only show it. Don't show it to me if it's not right. Like I can wait for a while if it comes to that. Yeah, sorry if the royalty fees were like a little confluent using. So like hopefully your next question is a little more straightforward scale. Yeah. You came up with those numbers? I think I always. I think it depends on the interviewer if like they want you to come up with it or like they want you to ask them. But this is totally cool actually. We'll go check how many titles like Netflix has. I thought it was like in the tens of thousands, but like it sounds low but like also maybe not. I'm like there's a lot of movies and then countries totally fine. And you did make a great point on I lost it. It will come to me. It wasn't like anything like engineering focus. It was like more like about the business and Netflix. Oh yes. You. You said we licensed this content. That was just like that made me smile because that you. You mentioned like titles we don't own and this is actually this system does do a lot of that at Netflix also for titles we do own. But that was just a side thing. I was like, oh wow. Like you. You kind of realize that out which is great. So just that random like the that side of it. Anyway, moving on to data structures. I think you did a great job. System A outputs. We didn't need to figure out the inputs for that system. So I think you're right. Title id most important rights, country id when you added start date, end date, that made it clear and I that made it really clear and I hope that helps you. And also the date created, which I'll talk about in the beginning in a minute. But that also really helped us out later on. And he also wrote us and B system C. So I think this is great. Like zero inputs for each system, which are all. Yeah, outputs for system A because they're sending it to us. Inputs for system B because we have our users writing it. And also inputs for system C because we're sending from B to C. So I think these are the right, like, requirements to write out. We didn't need like the. The other counterpart. Like we didn't need outputs for system C. This is great. Sounds very simple, but truly this system C just needs how much am I paying and who am I paying it to? And then we got into the APIs. I'll go to the whiteboard. Um, yeah, the. Yeah, we started to do this, which was great. Like, I know you sometimes it's depending on the question. Like, sometimes writing it all out helps, sometimes drawing it out helps. So totally agree. When you were like, actually, I'm going to start drawing this out. I think that was great to like, visually see it. And that's when we started to see like. Like, oh, yeah, how is system A going to talk to system B? You decided to do it, like rest and like fetch. And I'll talk about that at the end but. Or yeah, I'll talk about the at the end, but that was a very, like, synchronous approach. Like, hey, I'm going to fetch all this info and make sure I have it. Which is very. Makes it a lot simpler. That request either, like, succeeds or it fails. Like it guarantees. Just like ordering guarantees. Like, you make sure you get it and then you can kind of understand like the upper bound and like request time. So definitely a solid way to do it. And then system B talking to system. And then you have system B talking to the client. This made a lot of sense. Like, hey, now we have what titles. We have the rights information that needs to have royalty fees attached to it. Now our clients will come into the system and kind of tell us like, what they need. Didn't need to focus on, like, how that happens, just that, like, it needs to come in. And so you had this pattern of like, back and forth. Makes total sense. And then system B to system C, that kind of payment queue, which makes life a lot easier. And then lastly we had those kind of like auxiliary questions. You mentioned correlation ID for like, keeping track of like, observability. Absolute, like, great answer. Some people call like a trace ID. This just kind of like the trace ID and logging, I feel like, give you like 99% coverage. Like you. You'll know if something succeeds, you'll know if it fails, get alerted, kind of set up like your pager duty or whatever. And trace ID is like, great. Like, because it's a unique identifier and you can follow it through the system. And then similarly, we talked about, like, failures and being able to like, have that, like, some people call it like reconciliation. But that's like what you were talking about with the ledger, balancing the books. So for not dabbling too much in finance. Absolutely. Great. So, yeah. So overall, I think this is really good. I would probably rate it, like someone asked me before rating Netflix does it like, out of four. I think I'd probably do like a three out of four. And so I'll just go. And then I'll say, why? And so going back. So I do think this is really good. I think some of the other aspects I wanted to hear about was so for system A talking assist. So overall, great job. Thank you. Did great. Three out of four. And I'll put all these notes in the thing. Only other, like, constructive notes would be for this problem. I wanted to maybe hear about, like, eventing as a option or like, us talk about it, which I understand. Like, there was a lot of information to digest, but like, we know that writes. We had the premise that, like, system B only needs to do stuff if their records in system A. And like, maybe that's not the. That might not like, hit the light bulb in our brain, but if there's a lot of information and let's say there's no information, like, we don't. The client doesn't even need to check system A. So another idea is like eventing, where the rights information come to system B. And if there's information, then we, when the clients come, they can like, act on that information. So that's just another option. It would have been nice if we like, discussed it and then that takes our system A to system B. Communication from synchronous to, like, asynchronous. So they're like pros and cons of that. We might. It makes it a lot faster. But now we might lose events. Like, how do we know if we lost an event? So always pros and cons, never a right answer and then. But everything else I think was like, top notch. Like, we talked about observability, we talked about, like, failures. Um, you mentioned the sequel. I agree. This Is very like relationship heavy. Um, I think if we had more time, I did get the sense that you, you do know like you're scaling and I think we actually. No, we didn't, we didn't like need more time. This is like really good. So I think you like touched on the scale aspect of this and you were trying to keep. Throughout the interview you kept that top of mind. Like you're like, oh, like this is going to be a lot of information, but let's get like a simple solution and we could build on it. So I think that shown that shined through and I think in other interviews you probably have more time to discuss like load balancers, like blah, blah. We didn't need that in this case. But you mentioned caching and so it made a lot of sense. So for me that was the only thing. Not talking about eventing was like the only thing. Yeah, I was missing. But I think other than that, like your process is like perfect. Any questions? I know it was a lot.

Eponymous Pigeon: Well, just one with talking about eventing. It's just like if, if I were to have talked about it but still went with synchronous, would that still have been a problem or is it sort of like no eventing. It's kind of what we were looking.

Cool Koala: For.

Eponymous Pigeon: Kind of thing.

Cool Koala: Yeah, the way I said it. Yeah, I think it would. Yeah, I think if we discussed it, it could have, it could have brought it to like a four. If we made those trade offs, like if the, if we didn't have a million titles and maybe had like a thousand titles, like then this fetching would be good. And then if maybe I had said like if, if we did have a million, but I said if we go from like a million to like a hundred million and then we talked about eventing, I think I would have been like satisfied there. Yeah.

Eponymous Pigeon: Okay. No, that, that makes a lot of sense. I really appreciate it. It's been very helpful.

Cool Koala: Awesome. Any other questions?

Eponymous Pigeon: No.

Cool Koala: Cool. Yeah, but I think overall this is like, I think again your workflow is like perfect. I don't think you have to change anything. I think this question was a little difficult in terms of just a lot of different moving parts. But I can clearly see that you know how to design a system. Well, you are familiar with like your SQL. If it were a different database, we would have talked about those trade offs and your scaling is definitely there. So for me it was just this one, like eventing. But I think in, in the real interview you would have also done really great.

Eponymous Pigeon: That's all good, man. I. Yeah, this is my first design interview kind of ever, actually.

Cool Koala: Oh, wow. Amazing.

Eponymous Pigeon: Yeah. I got hired on my job now, and they already knew I. Because I was consulting for them, they already knew I could design and do the work, so they skipped that part.

Cool Koala: I know the feeling. So, okay, then, in that case, you. It's only up from here. Yeah. So take this as, like, a great starting point. You. I couldn't tell that this was your first interview. I will say that.

Eponymous Pigeon: Okay, good. That's good to hear.

Cool Koala: Awesome. Thank you so much. And have a great rest of the day. I hope the interview is helpful. Hope you're enjoying the platform. And have a great rest of the day.

Eponymous Pigeon: Very helpful. You too. Bye.