Beginner's Guide to Mobile App System Design (+ Tips for Interviews!)

Hinzugefügt: 2026-05-10

[00:00:00]Hey guys, welcome back to a new video.

[00:00:01]In this video, I will give you an introduction to mobile app system design. So, you will learn what even belongs to system design for the mobile app world. You will learn about making certain design decisions and how to make them and why to make certain decisions.

[00:00:15]You will learn about which things and topics to even think about when coming up with a mobile app system design because that's of course also a very common type of job interview that you are there and you should actually and share your thoughts about the system design of a maybe popular app like Instagram or YouTube and in the end to understand what mobile system design is really all about. There are three different zoom levels that we now want to consider. So you you really must imagine your app from a bird's eye view.

[00:00:39]You're looking on that app and then you keep zooming in into more details of the app and also internal details of the code, which technologies you use. And these three zoom levels are of course high level. So really just take a look at who uses your app, what is it even for? So which features does it consist of? What are non-functional requirements? What is the scale of it?

[00:01:00]How many users use it? That's what we'll take a look at in detail here. What this really consists of. We will take a look at the architecture. So that is then the the next step of the zoom where we then already at least take a look at the coding perspective at least thinking about how the code is structured. So which architectural patterns you use which approaches which practices and lastly we zoom in even more to decide about the specific tech stack that the specific features part of this architecture consist of. So decisions about which protocol do we use for certain types of communication. Is it real-time communication? If yes, how does the real-time communication work?

[00:01:34]How is the API design look looking like?

[00:01:37]Which external services does your app need to talk to? How does the DB schema look like? What are kind of data policies? Do you have an offline first approach? Where do you apply caching?

[00:01:45]Where not? All these decisions are then in the last step of zooming in. So the first step when actually planning an app that you need to think about is who's that app even for? So who is your user base? How are they like? So how old are they? Because of course if you're developing an app for a very young user base then you can make different assumptions about them than about an old user base. If you have a rather old user base that means you actually have to have completely different user experience principles and have to make it much more idiot proof because older people tend to not be so technical. Also older users often just don't work on the new flagship models and the the most modern smartphones but rather on older Android devices. So this also has requirements for okay which versions do I even target with this app. You then want to think about okay which languages do I even need to support? Which regions do I support? Is it just a Spanish audience? Is it a German one? Do I just support English? Do I support many languages? You need to think about things like profession. So can you actually group your users as a specific profession? Is it just a general consumer base or is it maybe an app for architects? Because that again dictates how you have to think about certain features, certain requirements because the moment you know that your app is going to be used by a certain profession, you can again make certain assumptions about that profession. So this context then really part of all these questions. What assumptions can we make about our user base and how does that change how we approach planning our app? Then after you know who you build the app for, you of course still have to think about what are you even building.

[00:03:19]So what does your app do? So splitting it down into features, thinking about what it should do. Um so here for example a social media, it would maybe have a profile feature would have a some kind of feed where you would see the posts from those people who you follow.

[00:03:32]So there should be a follow feature.

[00:03:34]Maybe there is a friends list feature.

[00:03:35]Maybe there is a profile edit feature.

[00:03:37]Maybe there is I don't know an inbuilt post editor or something like that. But sit down before you of course get into implementation and think about what does your app even do? Which features does it consist of? and what is the real goal of it? So these are real functional requirements. You say okay I have a profile that means uh users can upload a photo. Users can actually change their username. There is this concept of a username. Users maybe have an email that is not exposed. So these purely functional requirements and how the app should really behave on in certain features. But then there also non-functional requirement which is more about how should the features work. So to non-functional requirements we count things like battery consumption. So there could of course be a requirement that the app should limit battery use to a specific amount per 10 minutes of app use. I don't know. You can of course use metrics here. And this then connects to topics like okay realtime connections that's something to think about if your app needs that because real-time connections and keeping them up is quite battery expensive. So you want to think about how you optimize that to maybe not have five simultaneous real-time connections at once. Things like background work. How can you limit background work if battery consumption is a requirement? Heavy processing of course, media, all those are things that relate to a high battery drain, but also things like network requirements. Do you have to ensure a reliable network speed?

[00:04:58]So, is your app perhaps being used a lot outside? Are users mostly using it with a stable Wi-Fi connection? And it has completely different assumptions leading to different design decisions how you structure the app. Then if you expect your users to often use your app outside when they're in a train driving through a tunnel where the internet can drop and come back. All those assumptions about how your app is being used of course again change how you just architected and how you built it from scratch.

[00:05:25]Things like memory consumption is of course a big thing. We are on a mobile device after all. We we don't have infinite amounts of RAM available. So things like media uploads, do you perhaps have to chunk these? Do you have to split these down into smaller parts and then upload these smaller parts because you just can't rely on just reading in a whole file into memory because there may not be enough memory available if your app is working with large files. Things like performance of course are part of non-functional requirements. So do you have a specific call startup time that you want to ensure? Is there maybe a specific APK size? I count that as part of performance here. Network latency. Does your network speed actually must reach a specific threshold? Localization. We've talked about that before, but this is not just about languages, but maybe also do you have to support right to left layouts, which are often common in Arabic languages. And things like scale, of course, so how many users do you even have to support? How much does your app need to scale? Therefore, how much data does each user possibly consume here?

[00:06:22]There's of course something where you have much more architectural and system design decisions on the backend side since that's usually what stores your user data in some form and your mobile app then just interacts with that and just fetches the data for one user but still this has some impact on how you design the mobile site as well. Okay, then of course architecture is a thing to think about. How do you even plan to structure the code? Which external services do you need to connect to? So for example, a messaging service. If you have a chat app, uh authentication, of course, how does login work here? Does it work with I don't know refresh token?

[00:06:53]Does it work with a one-time password?

[00:06:55]Does it work with a two two-actor authentication? All those are things you have to think about before implementing the app of course I think like analytics. Do you even need to log certain user behavior? Maybe think about that before. Maybe there's a profile service or an external server that you connect to where you get users profile data from. But also of course the architecture itself. So how you really structure your source code in order for it to scale to the level that you need for your app. Sometimes you can stick with a simpler approach here of maybe just working with a UI layer and a data layer. If it's a simpler app and you know okay the the scale of this app will be quite limited as well and it won't need to grow to an infinite number of lines of code then you can keep it simple. But if you know okay we don't yet know what the future of this app is and maybe it becomes super successful and we need to set a solid foundation here for the app to really scale then you need different architectural principles and patterns that you choose.

[00:07:48]So this is then about decisions like do I use MVVM or MVI in the presentation layer. Do I use clean architecture? Do I stick to use cases? Do I stick to the repository pattern? And of course more such related topics. You need to think about how does your app actually communicate with the server. So just the fact that it has to communicate with the server does not yet dictate how that needs to happen. There are multiple different protocols we can think of. For example, rest normal HTTP requests client. So your app makes a request to the server server responds. That's a very common form of communicating with a server but definitely not the only one and not one that is always suited.

[00:08:22]Sometimes you want something like websockets for a real-time connection.

[00:08:25]So you definitely don't want to have something like a polling approach that just keeps executing REST requests in a while true loop just to refresh some data on the client side. In that case, you may rather want to think about a real-time mechanism like websockets or server sent events, SS where the server can just notify the client in real time about certain events happening for the client to then refresh certain data or things like GraphQL. Is that maybe a thing for your app? So do you maybe get very large responses but the app doesn't always need all of that then graphql can be something to look at. What system design also covers is the actual API design. So for example which endpoints can your app actually connect to. So here in the end API documentation. So you can make a get request to the profile endpoint to fetch profile data.

[00:09:09]You can make a get request to the feed endpoint here to fetch some posts here that take in some kind of cursa and a limit. So they in the end pageionate.

[00:09:18]Pageionation is also something you have to think about in the system design planning part whether you want that whether possible lists that you rep displays can go very very long and benefit from being chunked your database schema of course if you have something like a social media app again then you maybe have a users table. You maybe have a posts table and you also define the relations between those. So one user can have an infinite number of posts technically but one post always only belongs to one clear user. Those are rules at the system design level that you have to set here. Then maybe there is a a comments table where one post can contain multiple comments but one comment always belongs to exactly one post. Uh there is maybe a follows table.

[00:09:58]So who follows who. One user can have multiple followers and one follow or rather one follower can also have multiple users this belongs to. Think about things like data policies. So how do you even manage your data in the app?

[00:10:12]Is it an offline first app? Can you benefit from that? Does the app and the use case and the user base justify the overhead for having an offline first approach to just make it work as far as it can get in offline mode to be able to really freely browse through the app in offline mode without requiring an internet connection adds a lot of complexity but also a lot of good user experience and makes the app faster overall because you can instantly show data from your local cache and don't have to wait for loading something from the network. Then think about things like okay how do you even implement that? Do you stick to the single source of truth principle that you maybe just look at your offline cache and only load data and display data from the offline cache and then just populate it in the background when making I don't know API calls when having some kind of synchronization work. That's of course also something to think about. How do you make sure that certain elements and let's let's say we have an offline first note-taking app that if the user adds a new node in offline mode then we of course need to make sure that once the app goes back online that the node also gets properly synced with the server.

[00:11:11]How do you ensure that? How does this synchronization work? That's part of system design. Conflict resolution. So you have two devices that both use the same note takingaking app in offline mode. Both devices added the same node in offline mode and then come back online. How do you even know which node which version should actually be taken at that point? That's in the end conflict resolution. Of course, mobile apps very often cover some type of media. So first of all, think about the types that it actually covers. Do you support something related to documents, to videos, to photos, whatever kind of media type? Then do you have to upload these, download these? Again, these considerations. And do you maybe need to chunk these? And then also maybe image caching. If your app displays a lot of images, then you probably don't want to always fetch these from the network, but rather have some sort of caching mechanism on the client side that can simply display these images also when the app is offline. Security is a very big thing. So if you take a look at here authentication of course again mostly the security part here for authentication sits on the back end that is where you have to have a really careful implementation but still on the mobile side some part of that remains if you maybe work with tokens how do you save them do you encrypt them do you maybe need to save some other sensitive user data so working with all kinds of user data uh networking which protocols do you use by default of course the moment you work with HTTPS that is encrypted by default but sometimes you have special require requirements.

[00:12:34]Sometimes you have super strict um like a zero knowledge setup where the server never knows the user's password and never knows what kinds of files they may have uploaded requires a completely different authentication and security approach than a simple HTTPS protocol.

[00:12:50]Then simply sticking to the HTPS protocol and just exchanging data, making sure the actual communication is encrypted, but the server sees everything that was communicated. Once you've then actually deployed your app to Google Play, you often want to observe it in some way. You want to find out things like okay where on which devices on which device types for which types of users does the app actually crash? What are the crash locks? What are the analytics? How is user behavior like? Which screens do users very often visit? Maybe do more of that. Things like performance monitoring. What is the average cold starter time? What is the average, I don't know, network latency, the average time a request takes to your server? Maybe group those based by country. So you know, okay, certain countries have much slower requests than other countries, which you can again use to make certain assumptions and possible fixes to improve your app. Things like remote config. Do you actually want to be able to switch certain config flags remotely that can then also change behavior on already deployed apps on already installed apps to users devices?

[00:13:51]Things like AMB testing. Do you want to show screen A variant to one group and screen B to another group to find out which which UI structure actually performs better here? Then that's also something to think about. So this should have at least given you an overview of which topics to think about when coming up with a solid system design for a mobile app. And now in system design interviews as they are very common, you are often just asked to walk the interviewer through a specific maybe case study or a specific example of a mobile app to just share your thoughts about how you would approach that system design for that app, for example, WhatsApp. So let's actually go through that together and I will walk you through my thoughts about designing an app like WhatsApp. But just a quick note on these types of interviews, what this is definitely not about is that you really replicate and kind of memorize the exact system design of WhatsApp in this case how it really is in the real world. This is not what these interviews are about. In fact, in in the real world, such a system design approach also evolves over time. So this isn't fixed from the beginning on and then it will never change. But the goal of these interviews is that an interviewer just understands that you are able to make solid and well-reasoned decisions after all that they understand you're able to consider the trade-offs of different approaches and even be able to think about these approaches in the first place that you know okay we can speed up the performance by maybe adding a cache to a specific feature and then seriously considering that in the context of a specific app and just sharing your thoughts. So if you are in this interview, really just share as many thoughts as you have. Involve the interviewer in your thinking process when walking them through on how you would structure an app like WhatsApp. Of course, this is an interview. The real world is much more complex and they also don't expect you to uh know every single detail of WhatsApp. But being able to reason and go over these different topics that I went through here so far, that is definitely what is expected in these interviews. So let's just do this together here. uh so we'll define what is WhatsApp who uses that non-functional requirements that would make sense in this context which external services it may need the architectural considerations realtime connection is of course a thing here for WhatsApp the DB schema that the app may need offline first does it need that he has to know what are considerations here uh maybe read receipts so sometimes these interviews also go into very specific features of WhatsApp like tell me how read receipts work or how you could implement that because what seems trivial on the surface often very is often very complex the further you dig into and of course security and observability is a big topic here with WhatsApp. So let's take a look what does WhatsApp even do. So let's think about the features. The core of course a realtime chat uh in the end you can just chat with your friends be it in a group be it uh in a one-on-one chat that's in the end whatsApp is but it of course contains more than that as a feature.

[00:16:41]There's also media contact location sharing in a chat that needs to be supported. There are voice memos that are part of the chat feature, group chatting of course, and of course other features. This is really not exclusive.

[00:16:53]There's also settings and that kind of stuff. But we also have profiles, we have a stories feature, we have a voice over IP, so actual um calling in both video and nonvideo form. But we'll mostly focus here on this real-time chat feature because otherwise I will still be recording tomorrow. Okay, who is actually using WhatsApp or who will use WhatsApp? Assuming we are planning this app. Well, in the context of WhatsApp that's actually anyone with a smartphone. So that's of course an example of an app that is deployed to almost any device out there. Almost anyone has WhatsApp nowadays. Of course, if we exclude exceptions like China, which have completely different infrastructure, but really people from young to old in every country you can think of use WhatsApp. All kinds of phones therefore. So if everyone uses that or everyone could be a user then we also need to assume that there are people with very old phones that we need to support here. Non-function requirements. What does WhatsApp actually have to handle? Well, fast message exchange. That is the core feature of WhatsApp. That is really what we want to ensure. We can't rely on people always being on a stable Wi-Fi connection. They could be in a train in a tunnel and they still expect that yeah ideally the message gets delivered even if they are on a very very slow connection. So this is really core to the functioning of WhatsApp. Minimal battery use because well it can run on older devices and anyone who has used a smartphone for a couple of years knows that the battery won't stay at the exact same percentage that it was after you've bought it but it actually goes down. So you have less overall battery that you can consume if you have an older device.

[00:18:30]And for an app that you use every single day and possibly multiple times per day, it's of course crucial that it doesn't drain your battery because especially if you want to reach, I don't know, I think it's deployed to two billion users devices. If people go to the app settings, then notice, okay, WhatsApp actually shows on top of battery drain, then it's probably not going to reach those two billion devices. Things like memory, of course, uh we have possibly very very long lists of chats here with 10 thousands of messages. If you have a friend and you chat to them over multiple years, then this quickly sums up. So, we definitely want to have something like a pageionation approach.

[00:19:05]We don't want to load the entire chat message list at once. Uh we want to have media thumbnails. So, you want to be able to see roughly what kind of image got sent without actually loading that image, without having that data exchange because users may be on a cellular connection. Maybe they have limited data volume. things like APK size here.

[00:19:23]Again, older devices don't have that much storage necessarily. So, also want to make sure that the app doesn't grow infinitely and doesn't definitely get get larger than it has to be. And every common language and every common form of uh letters needs to be supported here because WhatsApp is really used across the world. Well, what kinds of services does WhatsApp need? Definitely a messaging server. So for an app of this scale, you typically um have these micros service-like architecture where you don't have just one back and you talk to but you have a messaging server.

[00:19:55]You maybe have a push notification or just a notification server. Here for the Android side specifically, you would want to work with FCM, Firebase Cloud Messaging, which is Google's solution for uh sending push notifications to WhatsApp. APNS would be the Apple push notification service uh which is well if you build the iOS side media service so for uploading files and downloads that likely something that the WhatsApp app communicates with uh maybe a contact service because as you know in WhatsApp you uh the app actually fetches the list of contacts fetches all the phone numbers and then compares with a server which of these phone numbers are actually registered to WhatsApp to just show you these contacts in WhatsApp as well and that has to be done somewhere by a service on the back end side.

[00:20:40]Things like authentication of course think about in WhatsApp here uh we stick to phone number verification. So you really just put in your phone number and that is all you need in order to uh have an account on WhatsApp. There is no password. There is just I think a one-time password for uh verifying your phone number. But once you've verified it, you can just use that phone number on all kinds of devices as long as you're able to reverify it. security service. Uh WhatsApp actually sticks to endtoend encryption. So security is a big thing here. So this service could involve things like the actual key exchange for uh the end to end encryption because with end to- end encryption uh that the whole concept is and the whole idea is that the server does not and can never see which messages are exchanged. So they have to already be encrypted on the client side with a key that the server does not see in that plain text form and then be pushed to the server. Because if the server gets encrypted payload about the message from the client, but the server does not have the key to decrypt that there is no way for the server to know what was exchanged and maybe a story service. Um, as I mentioned, we can go more into all these external and maybe something like a story service here. Um, just as an example, of course, there's still video calling, there is settings.

[00:21:52]I won't go into the details here, but just to give you an idea of what else you would have to think about. How is the app actually structured or how should it be structured? I have no idea how the WhatsApp app is really structured and how the source codes look like because I don't know it but well here obviously we work with a very high scale codebase you want to reach many users it should be maintained over years and decades so um here we typically want to stick to quite traditional architectural principles that are made to uh to scale that can dictate a good modularization approach so presentation layer typically MVI MVVM is the established standard on Android typically three layers sometimes four layers with an infrastructure In addition, so you want to have a separation between the UI, between your business logic and domain level concepts like what a chat message even is, what a profile is, what a user is, and of course the data layer that handles the entire interaction with uh the external services with the backend side and so on. Sometimes you also have an infrastructure layer for all the Android OS specific stuff. But that's also something uh to consider. In this case, obviously you want to keep the domain layer which is on Android quite optional. Uh but since it's a quite growing and high scale app, it definitely does make sense because there's uh surely plenty of business logic behind the WhatsApp app. But there are also apps that don't have that much business logic where the main business logic sits on the backend side and then it's also reasonable in your system design approach to drop the domain layer to just reduce the complexity of your architecture a bit because that can also be quite a big advantage if you have less layers to work on. As long as these layers still give you the right level of scale that you want for your app, we need to think about how we even keep the chat alive. How do we ensure this real-time connection between two parties or possibly multiple parties when they are in a group chat? And not just if you are actively looking in a chat, but also if you're looking in chat A and you get a message in chat B, this should also be received in the background and somehow then be shown when you get back to the chat list screen. So here for this birectional messaging the typical standard is websockets or some kind of uh adjusted protocol based on websockets. I think WhatsApp actually has its own protocol that is based on websockets here. But the moment both your phone when in the foreground and some kind of server needs to exchange data in both directions in real time. So the phone needs to notify the server in real time. For example, sends a message.

[00:24:14]That's something the server doesn't know but the phone does. And when the server needs to notify the phone about something that only the server does for example when someone else send you a message then we need both these directions and websockets are the way to use for that. Uh another protocol here would be server send events as I mentioned but this is just uh one directional where just the server can send real-time messages to the client but not the other way around. So not really suitable here. We then also need to think about push notifications. So, how does the app actually get those chat message notifications when it's in the background? Because you can only keep a websocket connection alive when your app is really in the foreground where at least has an active process on Android.

[00:24:52]But the moment it's killed, you still expect the user to see messages in the notifications when they get one. And that is where push notifications come into play. So here you have your messaging server or your notification service um whatever send these push notifications via Firebase cloud messaging or the Apple service to your phone when it's in the background and these will then make sure that you actually see the uh not notification on your device. Thinking about the database here again this of course very very simplified the real DB schema behind the WhatsApp app I'm sure is is way way more complex than this but again in such a system design interview it matters that you are able to think about possible tables how they may be linked to each other and that is what we can do here so certainly we will need to persist some form of messages need to persist maybe the context that that the user has they have an avatar URL um maybe a display name a phone number all these things that we need to save locally in our DB.

[00:25:47]Shared media, something to consider. So probably separate table for storing references to photos to videos that have been exchanged. Call history also as an example from a different feature. You actually have this history of calls in your um in your WhatsApp like bottom bar or so where you can see who called you and who did you call before and maybe your stories cache. This is also something explicitly included here because stories I think are a pure online feature in WhatsApp. But still uh it's very likely that if you are in offline mode, you will still see who previously posted the story. If you tap on it, maybe you don't see the story because you lack the network connection.

[00:26:28]But very often these large apps like Instagram, WhatsApp still have an offline cache for powers that are actually only inspectable like really inspectable in online mode but still ensure that you just have an a much richer look of your UI. So you still see ah there are stories even though you may not want to see these and of course it allows you a faster access. So the moment you then tap on the story you already have all the metadata of it available because it comes from your cache. So maybe just the story picture or so needs to be fetched. Now thinking about data policies. So things like offline first. Do we want to support this with WhatsApp? Yes, of course.

[00:27:05]WhatsApp is an app where you also expect to be able to see your messages when the app is offline. So here how do we ensure this with messages in particular? We have our composed UI. The user tap send and that's the moment where we actually want to make sure to first update our local cache with the single source of truth principle. That by the way is almost always the right answer for structuring an offline first approach.

[00:27:27]You want to stick to single source of truth and treat your local cache as the single source of truth. So you instantly save your message the moment the user tap send even if you don't yet get like the successful delivery receipt from the server that it was really uh reaching the server. But then you actually have some form of background worker like a work manager worker on Android that will simply keep trying to send this message.

[00:27:50]So ideally it sends it in the first uh go. But if that fails because of a missing internet connection because of the server not being available, then you have a reliable worker that keeps on retrying this with some form of uh back off and tries to deliver it to uh your server once the server comes back online, once the device comes back online, which is the more likely scenario of course. Uh but you want to have some kind of reliable mechanism that messages are really delivered when the first call fails. And once these are delivered well then of course you get some form of acknowledge from the server where the client knows okay the server has received that message. You can maybe update your read received to that the single check that the server has received it and then can also extend this with yeah checking if the other client has actually received it. How should conflict resolution work here? So let's say you have two offline instances of WhatsApp two devices. Device A addits message hello to hello world and device B addits the message hello to bye-bye world. The moment both these devices come online. Which of these rides should actually win? Should the edit from hello world go through or the edit from bye-bye world go through? Well, and the most simple conflict resolution strategy here is simply the last right win strategy. So you just track when was such a ride being made. So you just check when was this write made and the last one just went. So the one that was made the latest. So if you have two instances both in offline mode, this device made the right at 4 p.m. This device made the right at 5:00 p.m. Then this one actually sees and both these devices actually push that right to the server. The server sees, oh, okay, this one is more recent. So we take that one.

[00:29:30]That wins and the message is going to be updated with bye-bye world. More complex conflict resolution strategies here often involve some form of user interaction that the user has to choose a specific version that should be kept which involves a specific dialogue in the app that shows. But as for my but as per my knowledge that is not how WhatsApp behaves. When is a message actually being read? As I mentioned just wanted to include this here because very often this is a sample question in an interview that you just deep dive a little bit more into a specific feature of WhatsApp like tell me how read receipts actually work. And of course if an interviewer asks you to walk them through a specific detailed feature then it also matters more that you go more into detail because here we're of course looking at WhatsApp from a very high level perspective without deep diving into specific parts of it. But if you explicitly get asked such a question about read receipts for example then they also expect to share a bit more about maybe which fields uh the database t table contains where it's linked and how this really works and is ensured.

[00:30:28]But here of course you to think about which types of read receipts are there.

[00:30:32]We definitely have the send receive which is when the server has actually received that. We have the uh double check which is when the other app has received it and we technically have the state where it's really read. So this is also an important question to ask ourselves. When do we even consider a message being read? Is it when it was sent? Definitely not because the moment you send a message it's obviously not yet read by uh the other client. when it's delivered. So when the other client has received the message or maybe has been rendered on the UI, do we then consider it being read? Probably not because it just because it's rendered on the UI doesn't necessarily mean that the other party has really read it. So likely you want to have a mechanism to uh have it being rendered on the UI and really as a visible component in on Android the lazy color recycler view for a certain number of seconds so that the user is actually pausing there and actively reading the message. That is what leaves you the closest to real read receipts. But you can't of course control the the other user's eyes and see okay they actually look at that specific uh text in the app. So all such considerations an interviewer really wants to hear from you that you are aware of talking about these differences of be of being able to spot these design challenges in the first place. We need to think about media. So how does WhatsApp handle that? Well, we all know we can send certain images, videos, files, documents into any sort of chat.

[00:31:58]Well, we need to think about is there a file size cap? It should actually be.

[00:32:02]So, do we constrain how large the files could be? Very likely because otherwise people use WhatsApp as their own personal free cloud and that's probably not what you want. So, you want to limit that to something like I don't know 30 50 megabytes of file size. Chunking, of course, the moment you uh possibly want to upload a 50 megabyte file via a very brittle connection, then you maybe want to chunk it. So, you can also pause and resume these uploads. We've all faced this before. WhatsApp is very good at that um to not require you to redo a complete upload from scratch the moment something fails, but actually lets you resume somewhere in the middle because it has worked with chunks before. So, resumable uploads, thumbnails, and payload. Maybe when sending an image, you already want to include some form of a very blurry image version with a very small file size in that payload. So uh so the other party can already display something uh that that covers a little bit of what the image may be about but not entirely um and can load this lazily when it actually wants to see that. How does WhatsApp actually protect its users? So security is of course a thing.

[00:33:08]Authentication, we've talked about that.

[00:33:10]So phone number um plus SMS onetime password. There is no extra password that the user sets and to end encryption is a thing here. So the server never sees any sort of plain text of sensitive data like the the message payload key storage. Well for the cryptographics keys where do we store these on the client side? The answer here is almost always the Android key store which is the only safe place on an Android device that is really protected. Local DB encrypted. So that's also likely something WhatsApp does that it uh encrypts the sensitive data in its own databases because if it follows an end to-end encryption approach then you wouldn't expect to be able to see the messages in the local DB in plain text because the moment that's possible then uh it's it's super easy for other apps that uh yeah to to read that database table at least if the if the end of device is rooted observability so what do you actually need to know from a running instance of WhatsApp on a certain device crash reporting for sure that's something you typically always want for a deployed app instance. So here uh a special extra requirements comes into play because it must be sanitized. So there should not be any message content available in the crash report. So if your crash references some kind of um error message that involves the messages content then this is actually something that shouldn't happen with this approach of end to-end encryption and zero knowledge. So, an important consideration to make here.

[00:34:34]Things like behavioral analytics, that's something that's very likely going to happen with WhatsApp. How do you even use this app? Because that's in the end the whole business of all these big tech companies to collect your data. Maybe not which messages you exchange, but how do you use this app? When do you use it?

[00:34:49]Uh when are you actually on your phone?

[00:34:52]How long do you actually use WhatsApp for in a given session? That is what meta here very likely analyzes performance. So uh there there's definitely considerations here for app starter time that you want to measure the message sent latency. So you're very interested in finding out how long does it take for a message to be sent? What is maybe the media but what are also outliers there. If you have a huge list in your UI that's sometimes a little bit laggy. You want to find out are there lags? Do you have frame drops? All that can of course be measured and reported.

[00:35:23]Things like am testing. So maybe making some smaller UI changes. In my experience, that's not very common with WhatsApp, but much more with Instagram.

[00:35:31]They like to play around with different UI layouts and approaches there. But still something to consider here. If you actually want to test different variants of your UI and see which one performs better, which one um is something that users understand more easily, then think about an A&B testing approach. So take this really just as a a sample walkthrough of how such a system design interview could also look like. Of course, being able to make these technical considerations here, that is something that comes from experience, from really building apps, from diving into practice and something that I can't push into a 30 60 minute video. If that's something you want to learn for the mobile side, then the course that of mine that gets the closest to that is really the cotton fullstack developer bundle specifically with the example of cotton multiplatform. So, it covers system design for both Android and the iOS side and even on the back end side.

[00:36:21]So, you get to design a complete system for a chatting app. by the way. So it's very close to how WhatsApp works. So if you're maybe currently preparing for such an interview, then get that course bundle because it really covers like it has 50 60 hours of video content. So there there is so much to learn in that bundle. It is my all-time bestselling course bundle. So lots of people have that link is in the description of course. Hope this video was helpful and I'll see you back in the next video.

[00:36:46]Have an amazing rest of your week.

[00:36:48]Bye-bye.

[00:36:59]>> [music]