An Interview with a FAANG engineer

Watch someone solve the banking ledger problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type

Banking Ledger

Interview question

Design a Banking Ledger. - Assumption: Assume the frontend client exists/ ATM [ Multiple sources of transactions e.g. PayPal, Zelle, Direct Deposits / Checks ] - List expectations in terms of requests

Interview Feedback

Feedback about Indelible Torch (the interviewee)

Advance this person to the next round?

Yes

How were their technical skills?

4/4

How was their problem solving ability?

4/4

What about their communication ability?

4/4

Overall more relaxed and it absolutely changed the game! brilliant job! General Feedback - Excellent work scoping down the focus. It was good that you realized just how expansive the system can be and abstracted over all aspects of authentication and didn’t focus too much on nuances - Brilliant work thinking about the point on reconciliation. It was impressive that you immediately intuited this aspect despite not designing a banking system before. - We still spent extra time on requirements but you are doing very well with ensuring the interviewer is in the loop so this was time well spent. It felt justified and as the interviewer, I approved the discussion thus it gained you points. You also knocked off an important discussion on DB selection by engaging the interviewer. Excellent work. - Be mindful of the common terminologies. Summarize types of consistency on a chart, load balancing strategies, rate limiting approaches, caching strategies etc. I have been caught off guard myself by this. Here is a quick list of examples: - Types of consistency: strong consistency, eventual consistency, causal consistency, and read-your-write consistency - Load balancing strategies: round-robin, least connections, IP hash, and consistent hashing - Rate limiting approaches: token bucket, leaky bucket, and fixed window counter - Caching strategies: write-through, write-around, write-back, and read-through - Brilliant work bringing up MFA right from the get go! This is something very few people think about yet in a banking app, it is absolutely key. Even better, you made the token idempotent. - Good job separating out the expiry time from the token itself. This eliminates a core sec vulnerability in the auth system - Excellent work with the ERDs for the databases. This bit was clear and to the point. Only suggestion would be to lean to the interviewer and have a tendency to skip over sections that may not showcase new knowledge. Transactions would have one table, but you would not need to expand in depth on multiple user account types. Overall though, your knowledge here was apparent and very in depth. - Expand a bit more on regulations. It may be something probed on especially if the technical knowledge is detected to be sound. Think about multiple aspects of regulation that could be thrown in eg Data Deletion (This is the most common one). The key is to ensure data replicated also contains notes on regulations it is expected to comply with. A decoupled service/ API that regularly does this may be useful to design. You may want to list say the regulation, TTL for the data on the replicated data (Max age should be less than the compliance requirement to enable automatic compliance) - You touched on data tiering which not only helps optimize performance but also helps with cost saving. Reducing the size of the active indices really helps with performance. Perhaps caching statements could also help here to.

Feedback about The Legendary Avenger (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?

4/4

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

4/4

N/A

Interview Transcript

The Legendary Avenger: Hello.

Indelible Torch: Hello.

The Legendary Avenger: Hey. Hope you're doing good. How is your day going so far?

Indelible Torch: I'm good, I'm doing well. How are you?

The Legendary Avenger: I'm doing well. I know we've had an interview since the last one. I remember it was my feedback. It was very borderline. I felt as though for senior it would have been an easy ask for staff level. I gave some recommend questions on things to look at in order to convert. So maybe give me a run through of what you've done since then. That way at least I can come in know with us new set of difficulties depending on your practice.

Indelible Torch: I haven't done a whole lot actually. I've just given a couple of more interviews, just tried to get comfortable with the process and just to be able to think on the spot, organize my thoughts and present it during an interview. I've also started reading some more system design problems just to get myself familiar with a few more domains just so that if an unfamiliar problem pops up right, I might have some idea if I've done some prior reading on it. Yeah, I see.

The Legendary Avenger: Excellent. Okay. Yeah. And if I remember correctly, you are going through Alex Shu's book, right?

Indelible Torch: Yeah, I have gone through his book earlier. I just ordered his volume two. I've read like two problems from it. Haven't really read the whole thing, but yeah.

The Legendary Avenger: Excellent. Okay. And at least final line of question on that. Have you had any interviews since the last session and if so, how did they go or how did you feel they went?

Indelible Torch: No real interviews. I had a couple of mock interviews so they were both leaning higher. So that was an improvement from last time.

The Legendary Avenger: That is good. Excellent. Okay, cool. And so that makes sense. So maybe give me a run through at least for today in this case. Is there any specific aspect you'd like to focus on or do you want me to throw a problem your way and then we just agree through it?

Indelible Torch: Yeah, I think similar to what we did last time, let's just go through a problem and as you gave me some tips on what's expected out of staff level and what I can do to make sure that I don't get down leveled right. So those kinds of things would be helpful.

The Legendary Avenger: Perfect. Okay, that makes sense. I'll try and take you out of your comfort level for this one here. So I think I've been very interested in this problem because it's very fundamental. I feel like it's one of the high level ones, but we're going to try and design a banking ledger and for clarity here I'll give you some initial assumptions. That way at least we're not focused on the wrong aspect of the system. Assume the front end client exists and you can also assume it could be an ATM system or just zelle or support for PayPal. So basically the only thing I'll note here do note that it's multiple sources of transactions, e. G, PayPal, Zell, or even direct deposits checks. So we want to make an assumption that that bit exists. That said, when you are going through it, if you need any particular features from it, list expectations in terms of requests. So if you expect a request might come in from any of these clients, feel free to list it. Just give me the expected interface structure. But the core bit I want you to focus on is how do you even handle these requests from this system? Like if it's authentication, if it's transactions, security, et cetera. So I want you to be like the person behind the loop that nobody really knows. Now build that system out for me. Is that okay?

Indelible Torch: Yeah, sure.

The Legendary Avenger: It's a good challenge.

Indelible Torch: Sorry?

The Legendary Avenger: It's quite a good challenge based on how and for context, I'll even do this for you because I know you're a fan of Alex Shu. So I'll give you this banking ledger so that after you're done, you can go through the way Alex Hugh has done it so that you also at least have, you know, depending on what you come up with, also look into how they did it and then see if you can gain any lessons from it. Don't open this yet, but the point is, it's actually something that they discuss in depth. So I want to just see what you can do now and then how you can improve on that.

Indelible Torch: Okay, sounds good. Okay, let's start with the functional requirements. Okay, so there's like a lot of things, I believe, within a banking system or a banking ledger. So we want to at least narrow down a few requirements which we can discuss and we can go from there. Right. I guess the first thing that comes to mind is user sign up and opening a new bank account. Is that something since you mentioned that we'll be focusing on the ledger part of it. Right. So is this something that we can assume that is already done and we don't have to discuss this in too much detail?

The Legendary Avenger: Yes. So for now, assume that the user sign up experience exists. That said, there is one aspect that I'll need you to think about, and that's the authentication bit. So it will be good for you to talk about the expected protocols and mainly in light of how you use the tokens, because we expect the ledger system to be sensitive about the tokens. So just be mindful of that authentication bit, but you don't have to design the core user experience.

Indelible Torch: Got it. So I'll just write that down. Users already exist. We do need to make sure that we are authenticating the users properly. Okay. The second requirement that comes to mind is basically deposits. Right now there are different kinds of deposits. One is like cash deposit. Then we have auto deposits, like payroll, et cetera. And then as you mentioned, that there can be deposits from external third parties like PayPal and other yeah. Do we need to focus on all of them? I've never really worked on something like this before, but I would imagine that there is some sort of common ledger or a transaction processing system which powers all of these. Right, but having said that, there would still be different back end services handling different kind of transactions, and they'll have different kind of APIs that they might be exposing to the outside world. Right. So which ones should we focus on for this?

The Legendary Avenger: That's an excellent point for a person who's never seen this. It is actually impressive that you thought about that. And that process is actually referred to as reconciliation. And for reference, you've seen how in banks, sometimes you send money, but it shows on the account, but it still shows a spending until, let's say, the next day. So that process of resolving all of that is called reconciliation. And for our purposes, you can assume we have, or at least in our case, we are worried about designing an API where each of these services can communicate with it. So this is our internal API, but it has external facing endpoints. Right? So external facing endpoints. So this bit right here, I would want you to maybe design one or two endpoints where let's say paper can communicate with us. Same case, let's say ATM systems, our ATM systems can also communicate with us. So I would want you to think about if an ATM was to make a request and PayPal can make a request, is there something common amongst them? Is there something different? And how can I identify that as part of the.

Indelible Torch: It? Got it. I think another mention that as well. Similarly, I guess we have withdrawals. Right? So similarly, I would say you have cash withdrawal checks. You can have the authorized wire transfer and whatnot then third party apps as well. It will discuss how our internal service is going to look like. And we'll probably go through a couple of use cases with different I think other common feature is like users looking at their balance, something users viewing their balance, something that we should support. There's also like joint accounts. And whatnot is that something we want to discuss?

The Legendary Avenger: For now, let's not worry about that. Assume that those are all handled by the black box that you mentioned up there. So the front end client, assume that that handles all of that.

Indelible Torch: Okay, makes sense. Um, transaction history for a user. I think that's another common one. Is that something we should be including in the scope?

The Legendary Avenger: Okay, maybe let's make a quick statement on it. So assuming that we have a database and maybe talk to me, if you were to store transaction data in a DB, what kind of DB would you choose? Because I would imagine getting the transaction would be a simple query on that. So what kind of DB would you choose for that? Just to gloss over this?

Indelible Torch: Yeah, for sure. I think the obvious choice that comes to mind here is an asset compliant database since we'll be dealing with transactions. So I think like postgres or MySQL, something like that.

The Legendary Avenger: Do you have a preference between one of the two?

Indelible Torch: I have a preference for postgres because that helps with handling concurrent requests better.

The Legendary Avenger: Perfect. I think that's it. Full points. That's good. I think that's the point I was looking for. So let's keep going with this.

Indelible Torch: Okay. I think this is a good list to basically another thing that I just wanted to mention was maybe we not have time to discuss it, but like dispute and et cetera. Right. And then disputes there is fraud, fraud, et cetera, which needs to be there even if we discuss this or if we don't discuss it. But these are some of the essential things.

The Legendary Avenger: Let me generalize this into one point that I think would help address them. And particularly we'll call it security. Sorry, I don't know, I deleted them. So we'll call all of this, let's see and the reason I'm saying this way, security, regulation and compliance, they all fall under this bracket. But when you're going through the question, don't worry about this or this, I'll particularly be interested in this. And the reason is banks are usually global services, and so tax implications, let's say reporting and auditing are something that we expect. So when you're designing it, keep in mind that we expect to comply to government rules. So think of monitoring, particularly to facilitate this bit. And I think this is one bit of feedback I had given you last time, so how can we facilitate it? So make sure you pay special attention to that part. Okay.

Indelible Torch: Okay. Makes sense. Yeah. We can discuss the reporting bit as well. If you're okay with this list or if you think we're not missing anything obvious, then I would like to move on and discuss some of the non functional requirements as well.

The Legendary Avenger: This oxy, this is good.

Indelible Torch: Okay, let's look at some.

The Legendary Avenger: One.

Indelible Torch: Apartments. Okay, let's quickly see that. As you mentioned already, security is pretty important. Security privacy is kind of given that it's a banking application, we need to make sure that it's secure. User data is private and only visible to authorized parties. Um, second thing is that system should always be consistent. So high consistency, we don't want no partial transactions. The system should be highly available. This one is a little debatable. I've still seen some of the banking apps, especially their online functionality. Sometimes they do take some downtime to resolve some issues. I don't know if it's related to compliance or whatnot, but they do prefer consistency over availability.

The Legendary Avenger: Let's actually think a bit further about that. So when it comes to consistency, what type of consistency do you typically see with banks and what type of consistency do you think makes sense?

Indelible Torch: The consistency that I see is in the transactions. Right. So basically there won't be a case where, let's say a transfer was initiated and a withdrawal happened from one side, but the money never showed up in the second account. Right. So the data consistency is always there. But consistency with respect to all the different services being available all the time, that's not necessarily the case.

The Legendary Avenger: Makes sense. Let me be more specific about what I'm looking for here. I will imagine you've seen how with banks, when you make a withdrawal, it might, yes, reduce the amount, but the transaction will still say pending until the next day, maybe at midnight, they resolve all of it. And then now you see the fully updated balance. So I'm looking for the flavor of consistency here because I think it could be immediate consistency. It could also be eventual consistency. I'm curious, what type of consistency do you think would make sense in this context and why?

Indelible Torch: Okay, so I would say eventual consistency with respect to the balances and everything. But I do think that there has to be some sort of most recent view allowing users to see what's the yeah, I mean, strong consistency. Yes.

The Legendary Avenger: That'S the term we're looking for here.

Indelible Torch: Okay, I see. Yeah. I guess when I mentioned high consistency, I should have said strong consistency there. So that's what I meant basically when I said that.

The Legendary Avenger: Okay.

Indelible Torch: There shouldn't be like partial transaction or anything. Yeah.

The Legendary Avenger: All right. That makes sense. I was drilling that particular point because high consistency didn't make too much sense. And I wanted to make sure at least we refresh on those terms. But that's good. Think we can keep going.

Indelible Torch: Yeah, makes sense. Let's quickly talk about the scale of the transactions and data that we are handling. How many users should we assume to begin with?

The Legendary Avenger: For now, let me make your life easier. Let's not worry too much about traffic. Particularly. We can assume it's in the millions in this regard, but you don't have to do any numbers calculations. That said, I would want you to think about API design, and I also want you to think about how you would actually make this a global service. So when you're designing some of the components, assume that we are receiving traffic from different areas, different types of, let's say, currencies. If you want to have some central service, I would want to hear about that. But for now, don't worry about the cost field. Just assume it's in the millions of users.

Indelible Torch: Okay, got it. Yeah. I think we can talk about some of the points that you mentioned as we go further into the design. But let's talk about the API and how that API is going to look like for some of these things.

The Legendary Avenger: All right, that makes sense. Let's do great.

Indelible Torch: So for API, since we said that okay, we are not worried about the user sign up, but we are worried about making sure that the user is authenticated. So regarding the authentication bit, one approach that comes to mind is to use web tokens for authentication. And the reason why I'm saying web tokens is that they are basically easier, they are lightweight in terms of how much state is required on the server side. And also since it's a banking app, what we can do is we'll have our web tokens which are somewhat short lived. So what's an ideal duration? We can probably discuss that, but at least in my experience I've seen most banking applications will kind of log you out after like let's say five minutes if you're not doing any activity, right?

The Legendary Avenger: Makes sense. Let's expand a bit more on that point. So I'll just do this quickly. That's a really good point. I agree with you. So I want you to fill this in for me. So verb. So let's say we have a V one and then let's say generate token or something. Maybe I'm giving generic names here and then maybe some account ID here. Assume something along the lines. So I want you to talk in depth to me about multiple aspects of this. And then when you fill this in, I won't ask you any other questions about the API. So then design the request structure. So the payload here and then I also need to design the expected response. And specifically here I would want you to talk about status code and then any other information that you think might be useful. So I want you to dig into this BT and particularly talk about the token types authentication methods and then fill this in for us. That way we can make sure this is structured enough. Does this make sense?

Indelible Torch: Yes. I also wanted to briefly touch on two factor authentication for some of the things like initiating a transfer or initiating some kind of withdrawal. So that's another thing from security point of view. Yeah. So the generate token request, so this would be very much like an authentication request, right? So to generate a token we'll need the username and the password, right? And then it can return you after verifying the username and password. This would be basically the verb would be a post here. Then it can be a token. And then to make life of the client easier, we can also return the expiration timestamp. So this is just like a timestamp which is a number. So why I'm saying expiration timestamp can be returned here is that so that the client knows that okay, if the client needs to, let's say notify the user that hey, your session is going to be expiring soon or what have you, they can do that without really querying the server. Again, I would say on similar lines there can be a refresh request as well where you just provide the token and say that request type is refresh, right? So in that way we say that okay. The user is still.

The Legendary Avenger: I'm curious about one thing here, because the moment you mentioned it, this is actually exactly what I was targeting. So I want to have us dig into this discussion a bit more. So the first thing I want us to think about is this part here. So you chose post as the bub. So is there a reason for it? Can you see any issues potentially happening if we use a post request?

Indelible Torch: So what else would I use?

The Legendary Avenger: Yeah, give an example.

Indelible Torch: Yeah, sure. I could use a get request. I see. Like from a restful perspective, post is something that generates well, it is generating a new token, right. Get request is another option, but then you'll be specifying URL parameters in the URL, which if you're doing it via browser, that may not be the best choice, is what I'm thinking.

The Legendary Avenger: Is there an issue that you see that could happen with the post request? And particularly I can give you an example. Let's say I have three browser sessions, maybe one on my main computer here, another one on, let's say, some public computer, let's say, your wife's computer that gets hacked, and another one maybe on your phone. So if I sign in on all these devices simultaneously and they east use post, do you see any potential security vulnerabilities with that's? Similarly, let's say I open three tabs, one being, let's say, incognito, and then the other one normally, and they all make a post request. What would happen in that case?

Indelible Torch: Right, so in that case, I think what you're saying is that if you get multiple post requests when there is already a token which is associated with the user, so I guess we can return the same token. Let's say if the multiple requests are coming from the browser itself, then the back end should be smart enough to recognize that, okay, the user agent is still the same, then just return the token that we've just created. Right. And if, let's say, the request is coming from a different device, maybe the token can be device specific.

The Legendary Avenger: That's it. So I was going to say this is actually I'm pushing on that point because that's exactly what the put request is for. So it's basically a post request that is IDE important. So when you make the request, if a token is already there, it will return the same token. So this maintains consistency with the session expiry. Right.

Indelible Torch: Got it.

The Legendary Avenger: Okay.

Indelible Torch: Yeah, you're right. Put might be a better verb here. Right? Yeah, that makes sense.

The Legendary Avenger: Awesome. And then the other question I have is particularly with this one here, okay. Put will somewhat address it, but if you go with this structure, at least in my mind, it seems as though we are going with a client managed token. And I think you hinted at this by saying that way we don't have to make a request again to the server to refresh the token because we have the expiry. But can you see any potential vulnerabilities with this happening?

Indelible Torch: Okay, yes. Just to clarify, so my understanding is that the token that you have, basically it's an encrypted info, right? So the client doesn't know how to interpret that. So the expiration timestamp is still encoded in the token and is still managed by the server itself. But it's an info that's provided to the client. Let's say if you have a mobile client interacting, and I would usually see the mobile client telling you that, hey, your session is expiring in so much time. Right. So to support that kind of functionality, that's why I'm returning it here. I don't necessarily see that to be a security concern.

The Legendary Avenger: I see your point. The only reason I was asking that is because typically JWT, the expiration will be part of the token. So if you decode the JWT token and typically the client will do that, the token will have the expiration as part of the data. And that's actually where I was a bit concerned. But in this case so this is their payload, not the token. So it's a combination of the payload and extra information, which is the expiry, which is good. So that eliminates that makes sense.

Indelible Torch: Yeah. The client wouldn't know how to decode the token. Right. That's why I was returning. Okay, I think we're spending too much time on this. Next. What else do we have? We have authentication, we have deposit. Okay. We have withdrawal, we have users viewing their balance. Let's go with the easier one. I guess that is viewing balance. Right? So that's going to be a get request. So v one balance.

The Legendary Avenger: Let it.

Indelible Torch: Could be one way of doing it, or maybe the other way of doing it is like this. And with an account ID.

The Legendary Avenger: Don'T worry about the rest of them. I think the core bit of that one above, I wanted to just make sure we have that in depth discussion, but I trust your API knowledge now, so I think you can skip over this section.

Indelible Torch: Okay, let's move on to the database entities that we would need. We'll need a user entity with some attributes, let's say email, et cetera. That's user entity. Then we'll need an account entity and then Account would have an account ID. Another thing that comes to mind is the type of account check. Saving balance is another office one. And there might be something else, but these are like the major ones. Then there has to be a user account relationship table where you have the user ID and user ID and account ID at the very minimum. And why I've kept it separate is because usually you can have joint ownership and whatnot. So one user can have multiple account and one account can be linked to multiple. So it's like a many to many relationship.

The Legendary Avenger: Makes sense.

Indelible Torch: That's why then comes a transaction entity. So this should have our transaction ID. It should have some type withdrawal. Is it a deposit? Now it can have an amount field. Right. Then it have an associated account. Now I guess question here is like does one transaction belong to one account only or is it a multiple account thing? In my head it's one account only because you have transactions coming from third parties or external banks. And whatnot for example, in this case, if we are talking about a transaction which is happening within the bank, let's say from one account to another account, I would assume that there is two entries posted in that, right? One for withdrawal and one for deposit. Right? That's what I'm thinking.

The Legendary Avenger: That makes sense. Okay, I agree with that approach.

Indelible Torch: Yeah. And this would allow us to basically get the transaction history associated with the particular user bank account. We haven't really talked about the scale of the database, but in the interest of time, I'm just going to share my thoughts briefly. I'm going to say that it's going to be a relational, relational database. And then since it's a worldwide, let's say a global bank, let's just assume that the scale is high enough that we'll need to do some kind of sharding. And the most obvious choice that comes to my mind is sharding by the user ID. Because most of the operations that we are going to do here, at least the user facing operations that we'll be doing here, will be limited to a particular user's account or will always have the user info associated with most of these operations. Right. So we should be able to target the right partition based on the user ID.

The Legendary Avenger: That makes sense. And out of curiosity, are you also going to do replication in this regard?

Indelible Torch: Yes, replication would be I would say it'll be like a primary and follower with multiple followers.

The Legendary Avenger: All right. And for the Replicas in this space, given that it's a global service, are you going to globally replicate or are you going to do it with some sort of heuristic particularly? I'm just thinking if we, let's say, want to support users both in Europe, both in the US. Maybe somewhere in Asia and Africa, then do you want to replicate US data in Europe or is there a criteria you'll be mindful of?

Indelible Torch: So this should be local to the region. So there'll be replicas. Usually if we're talking about, let's say Amazon AWS has a data center and then they have Replica which are like multiple availability zones in the same region. Right, so that's how it will be. But it does present a challenge in the sense that let's say a user moved from the West Coast to East Coast, then how do you handle that kind of scenario? Right. So I would assume that there is some kind of a backend service running or which gets triggered, let's say when a user basically accesses it from a location which is not his primary location, and then some kind of data migration happens for the user. So that basically they don't experience that same latency once they moved. So that kind of design is coming to my mind.

The Legendary Avenger: Makes sense. I agree. I think that makes sense. And do you see this in addition to this, do you see this being any problematic, especially from a compliance perspective and particularly tax?

Indelible Torch: Yeah, that's another thing that I wanted to mention. Basically limiting the data to a particular region would also enable us to meet any data regulations that are there. Right, but yeah, if they're moving and then I guess that does bring up that question that, okay. Now if the user has moved, I'm not really sure what the regulations say in those cases. Right, so let's say if the regulations don't allow us, then I really don't know if we are allowed to cache it temporarily or what happens in those cases, or the user has to live with some latency in terms of accessing their data.

The Legendary Avenger: That makes sense. Okay, so I'm being mindful of time here, and so I'll ask you one more question that I think we should spend the remainder of the time on. So we have talked about regulation. We have talked about what do you call it, studying in this regard. Now, I'm curious about the process of reconciliation particularly. So maybe at least for the design, for diagramming purposes, just design for me how you would actually reconcile this. And I would urge you to think of one bit. So we know we'll have data or transactions that happened ages ago, many years ago, and we still want the users to have access to them, but we know they won't be accessing it immediately. And you'll also have transactions that are happening recently and we'll probably also have statements. So I'm interested in three sections here. One, I want you to talk to me about the storage architecture for historical data, recent data and recently seen data and their most recent transactions that are actually pending. So I want to see the architecture for the three of those. And then I'm also curious about how you're going to resolve those recent ones. So I want to see you just design that component there. So if you want to diagram that, that's okay. If you want to just talk about it, that's also okay.

Indelible Torch: Yeah, I guess we can shift to a whiteboard. Yeah, okay. So as I mentioned initially, right, so we have so it, let's call it, let's call it transaction service. I'm just drawing the service bit here, right? So this gets the user request. I would assume there is a load balancer here and this is like a distributed service. It has some sort of cache for validating or we discussed actually using web token, so maybe that's not even required.

The Legendary Avenger: So.

Indelible Torch: It validates the session for the user and then it goes ahead and posts the transaction into a relational database. Transaction goes here. So now what's the lifecycle of this transaction? Right, so I would assume that there are different types of transactions here happening. Some of them are just transfers between banks which will be resolved pretty quickly. And then the other ones are, let's say some kind of wire transfers or some other systems which would take some time to resolve. Right, so I would say the transaction basically has a status bit and it gets posted as an initiated or something. And then what we can do is after initiating it here, it can probably put it into some kind of a message queue to have that transaction being have whatever the next step is for the given transaction to go through. Right, so that's one thing that I'm thinking now. There has to be some kind of a generic service here which can be transaction handler should basically know how to, how to, how to, how to further process this transaction. Right, so so this can trigger different services based on the type of transaction and whatnot right. If it's wire transfer, there might be a wire transfer service that gets triggered if it's a third party transaction that needs to be sent to a third party. So there'll be different services consuming and consuming this. And then what they can do is basically update the status service. They can update the status back onto a relational database and post the update back that okay, what's the status of this transaction now? So that's the kind of flow that I'm thinking that happens.

The Legendary Avenger: Maybe rather than the parties themselves updating our DB because that could potentially cause vulnerabilities. Maybe we can respond based off of the response from these services because they will be individual APIs, right? So our transaction handler will send a request in. This can maybe be like a queue, as you said. It can send a request to the service, it receives a response and then it be the one that makes the update rather than these systems themselves being given access to the DB. What do you think?

Indelible Torch: Yes, I think that makes sense. I should have added that instead of like I don't know why this thing is don't know why this text is below should be here. Yeah. So I would say there is another service which kind of deals with response. We can call it transaction resolver. Then based on what the payload is, it goes ahead and updates our database here and that's basically for the recent transactions which are there. Right. And then we can have some kind of archive DB as well, which makes sure that so how would that work? I would say it can be like a cron job or something, right? I don't know if we have so this is like a data archiver and this maybe runs, let's say, once a month per user. Right. And then what it does is it goes ahead and it takes this data, maybe does some denormalization on it, and then puts it in some kind of a NoSQL storage or some kind of object storage for retrieval later.

The Legendary Avenger: And just out of curiosity, because that was actually another point I was looking at, I don't know if you've seen this terminology in AWS called Data Tiering, but this is exactly where you have some data on memory, some of it on cold storage. And can you see any benefits of this approach other than, let's say, the fact that I'll mention the obvious one here. It helps with cost saving because only the most recent data is in the quick memory. Can you see any other benefits in terms of performance?

Indelible Torch: Yeah, definitely, because this helps with how much data a database shard is storing. So the smaller the footprint of the data, the more data is kept in memory by the database itself. Right. So your transactions, your reads are faster, basically. So it helps with that aspect as well. And then also helps you, going back to your point of cost, keep the footprint of these machines smaller, because the bigger the machines that you provision, the more expensive they get.

The Legendary Avenger: And it also follows the user pattern. Typically, people don't look at very old transactions, so we don't really need to commission the most powerful machines to serve this. They can be served on demand and then maybe perfectly cashed, but for the most part, we don't want to keep them quickly accessible. That's why we have statements and you have to actually load through the app before you actually view them.

Indelible Torch: Right, yeah. Makes sense.

The Legendary Avenger: All right, I think this is a good point to stop because we have about six minutes left, but overall, I think I'm very satisfied with this answer, but the same way we did it last time, maybe. Let's start with you, like looking back at paint, or is there anything else you wanted to add just before we end? Just interrupt.

Indelible Torch: No, I think sounds good. Let's go to the feedback. Right? Yeah. All right.

The Legendary Avenger: So looking back at it, what do you think? You did well, and what do you think are points of improvement?

Indelible Torch: I think one thing I did well is that I was relaxed kind of throughout this process. I think it helps that I've talked to you before as well. I spent a good amount of time on Functional Requirements and listing down the various use cases, and that's kind of a good thing. So that at least I'm able shows that I was able to think about the problem. Holistically give different things that you would have to think about. So that part I thought was good. I think I covered non Functional Requirements pretty well with that. Bad terminology for strong consistency. Should be more mindful of that. API design.

The Legendary Avenger: Keep going. You're right. Sorry.

Indelible Torch: API design I think it was generally okay. But I can spend more time on going through the nitty gritties of I actually know where post and put should be used. But sometimes it's hard to realize while you are interviewing. Right? So, yeah, I can definitely use more practice there. Again, I think the entity diagrams I think was pretty okay in my head. Can use better time management and maybe give some more time to the actual design diagram.

The Legendary Avenger: Yes. TLDR I think, you know, this is a pass. At least even for me, this is easy. It's really easy to see the improvement. And you're right. In fact, maybe the first piece of feedback I should have said, it's really great that you are relaxed. I could pick it up. The pace of your speech was excellent. And you did one thing. There's one behavioral thing that I usually find it hard to communicate to candidates, especially if they're not comfortable. You are okay asking me to skip over things. I feel like candidates in an interview, you tend to be afraid to do this, but it comes from a point of not being relaxed enough. But if you ask, it's not harmful and it's okay because sometimes there's things that the interview is completely not interested in. So I feel like much of what I'll give you feedback on here is more interview specific and not content specific. This time you managed to bring it all and this was actually a really good performance on my side. And so, as you can see on my feedback here, I think you kind of intuited much of what I was going to say. In fact, the terminologies are the same. You say just being mindful of the common terminologies. Those are the bits to be mindful of. I gave you like a quick summary. And the funny thing is, I know this actually is a flustering bit. In fact, I've been caught myself saying round robin being another rate limiting approach. I think I say it no. Yeah, I said a rate limiting approach. We can use rate limiting approaches like round robin. And then it hit me immediately, what the heck am I saying? And that kind of thing happens. And so just practice helps, of course. And in my case, the solution I ended up with was just having sticky notes to avoid that kind of mistake. But of course, more practice usually makes these things more intuitive. They're honestly confusing. They're way too many concepts. So at least for me, I typically don't take it out against the candidates because frankly speaking, even us, we don't necessarily configure load balances daily. So you might be a staff engineer, but typically you'll do it on demand and you'll read the documentation. So that's something I understand. But given the environment you are in right now, you'll find companies being pedantic about some of this bullshit. And so it's important to be mindful about that. But overall, I think this is an excellent performance. And I think you can also tell and bits of refinement are more or less interview specific. I think I printed that bit out here. So let's see. Give me 1 second. Ah, yeah. So this right here so only suggestion here will be when you find yourself maybe doing something that feels repetitive. I could tell, like, let's say you've designed the user diagram. You've designed the account diagram, you're going back to the user diagram. I know that sometimes as an interviewee, you can find yourself going down a rabbit hole and it's okay. I mean, you kind of showcase the ability to do this, but I'm just going to call it so that you're mindful of it and feel free to do it again in real interviews. If you think it's redundant, feel free to abstract over interest. You can just mention we could have extra information here, maybe things like addresses. But if they're not going to be useful for the ERD, skip over them. And this applies to pretty much any of the component. Like if you're designing the API, it doesn't need to be an exhaustive request. You maybe do it once or twice. But if there's any extra additive information, you can just tell the interviewer, I can include extra information like this and that. Do you think it's important I write this? Just bring them in. That way when you skip over it, they're okay with it. That way they just see that you know what you want or what you could add there. But at least for the interview purposes, it's not going to add much. So the idea here is kind of refining the amount of information you're focusing on so that it's all additive. You don't want to be repeating the same information. You want to make sure that every bit of information that you're writing in is expanding the interview, is expanding the interview, or is adding to the information you've already shared. So just more practice. I'll say at this point, honestly, I'll give you, let's say, four stars for pretty much everything. But it's more like you probably need one more. Don't jump in. Honestly, if you jump in tomorrow, you'll probably do well. But in my case, I want you to actually blow it out of the water. I want you to get the best of the best offers. But for the most part check. You have the knowledge, it's apparent, the bits of refinement, I think those are clear. So maybe get one or two more interviews in just to make sure that you're not caught with some of these silly details. Summarize them, summarize the notes. That way they're not an issue. But overall, I could tell that you're more comfortable with the process and I'm really happy to see that.

Indelible Torch: Awesome. Thank you so much. Would this be a pass for, let's say a staff level or do you think still needs more work?

The Legendary Avenger: For me? Yes. I would actually pass you for that. But this is the thing, senior, it's actually strong pass staff. I'll say pass leaning, strong pass. That said, I want it to be strong pass for staff. And that's why I recommended maybe get one more practice in. So that those little bit, the little bits that we talked about, like, let's say the terminologies that caught you off guard here, make sure that you refine on those. That way, it's essentially spot on every aspect. So maybe get one more in. But I frankly feel like if you have interviews tomorrow, you'll probably be fine. That's kind of my point on this. Okay.

Indelible Torch: I actually have one on Tuesday. Yeah. Okay.

The Legendary Avenger: You will be fine.

Indelible Torch: Thank you.

The Legendary Avenger: And go in. Relax. Be relaxed where you are today. Don't be flustered. Your knowledge is apparent. And with that relaxed attitude, you're able to really move at a fast pace. So you did a really good job here.

Indelible Torch: Okay, awesome. Thank you so much. Have a good day. Good night.

The Legendary Avenger: Awesome. All right. You too. Have a good day.