Speaker A
Hi Meha, how are you?
Mock interview on designing a scalable Facebook-like newsfeed app with offline support and efficient pagination.
Key Takeaways
- Designing scalable social media feeds requires careful handling of pagination, offline mode, and real-time updates.
- Cursor-based pagination is preferred for consistent and efficient feed loading.
- Offline support with optimistic writes and synchronization is critical for user experience in mobile apps.
- Layered architecture and separation of concerns improve maintainability and scalability of the client app.
- REST APIs with JSON are practical for backend communication, with potential extensions for real-time features.
Summary
- The video is a mock system design interview focused on building a Facebook newsfeed app with two main screens: a feed list and a detailed post view.
- Functional requirements include displaying posts with text, images, videos, likes, comments, infinite scrolling, and offline mode support.
- Nonfunctional requirements emphasize scalability to 100 million users, low latency, data efficiency, and synchronization for offline interactions.
- The backend communication is designed using REST APIs with JSON, supporting cursor-based pagination and potential real-time updates via WebSockets or server-sent events.
- The interview discusses API design, including pagination tokens, request types, and user interactions like likes and comments.
- Client-side architecture is layered, leveraging repositories, local data stores, and reactive programming to handle offline capabilities and data synchronization.
- Optimistic writes are used for offline user actions, with retry mechanisms and user notifications for failed operations.
- Navigation and UI state management are handled with a router and backstack entries, supporting smooth transitions between feed and detail screens.
- The discussion includes architectural best practices such as repository pattern, dependency injection, and separation of concerns across presentation, domain, and data layers.
- The interview concludes with feedback on the candidate’s technical proficiency and architectural decisions.
Chapters
- 00:00Introduction and Problem Overview
- 02:08Clarifying Functional Requirements
- 04:04Content Types and Global Audience
- 06:10Nonfunctional Requirements and Scalability
- 11:17Backend Communication and API Design
- 13:38Pagination Strategy and Cursor Design
- 16:07Client-side Architecture and Data Handling
- 25:58Offline Support and Optimistic Writes
- 31:16Navigation and UI State Management
- 39:03Architectural Patterns and Interview Feedback
Full Transcript — Download SRT & Markdown
Speaker A
I'm good. Thank you so much for giving me some time.
Speaker A
Yeah, sure. Are you ready to start our mobile system design mock interview?
Speaker A
Yes.
Speaker A
Okay, cool. Let's jump right in. So, do you see the mockup on the screen for our problem?
Speaker A
Yes, I do see. So, I would love to do today a classic Facebook newsfeed problem.
Speaker A
So, we need to design an app that has two screens. The first screen on the left is a list of posts where we can see an author's name, avatar, and a timestamp, and also post content which can be a
Speaker A
text, image, or a video, or both combined. So, for example, we can have a text and an image. Also, we have the ability to like and comment on a post. And if we click on a specific post, we go to the
Speaker A
second details screen. So here we see the same information, but additionally we see a list of comments.
Speaker A
Mhm. Yeah, this sounds really amazing. Especially all the social media applications need to have some kind of feed to basically keep the users engaged for a longer time. Before I jump into the design, can I
Speaker A
ask some clarifying questions?
Speaker A
Yeah, sure. Let's do that.
Speaker A
Okay. So, let me say, let me just leave some kind of functional, nonfunctional, and anything that is out of scope here.
Speaker A
Alright. So, this is very clear. We want to basically have some kind of view, the list. Basically, number one, we want to view the list of feeds or we call it post items.
Speaker A
Mhm. I imagine this will be, and we also want to support user interactions. I believe the user should be able to see.
Speaker A
So in the comments, do we want to show the comments count or the likes count, or should the user be able to comment?
Speaker A
Yeah. So we should be able to see the like count and comment count. And for simplicity, let's implement comments on the second screen.
Speaker A
So where we see them. So, for example, if we click on a comment button, we go to the second screen and comment there.
Speaker A
Or we can have like a popup on the main screen.
Speaker A
Mhm. Yeah, that sounds good. All right.
Speaker A
The other question is, I'm imagining this should be like an infinite scroll level list, right? So when the user reaches the bottom, it can basically keep loading more content until it reaches the end of it.
Speaker A
Okay. So it has to be an infinite scrolling list. Let me just zoom.
Speaker A
Okay. Alright. Another question is, okay, we want to support all the different types of, you know, different kinds of content here. Text, we want to have image, video, and combination of them.
Speaker A
Should we do, do we end the detail screen where the user can go in?
Speaker A
What about creating a post? Maybe we don't want to create a post or let's leave it out of scope.
Speaker A
Okay. Creating a post. What about real-time updates from, you know, like when the user adds a new post or updates a new post? Do we want to show to the users in real time any comments
Speaker A
being added? Do we want to show real time or if the user is offline some kind of push notification? And if we have time in the end, we can discuss it, but it's not a high priority feature.
Speaker A
Okay, maybe if time is permitted.
Speaker A
All right. And what about what scale of the user base are we looking at?
Speaker A
Yeah. Let's assume we can have up to 100 daily active users for this app.
Speaker A
100 daily active users?
Speaker A
Okay. 100 million? Sorry. 100. Sorry.
Speaker A
Okay. Yep. All right. And what is the geography? Are we targeting global or a specific area?
Speaker A
Yeah. Let's assume we have a global audience.
Speaker A
Yeah. Because this kind of changes the design because I think we might need to support all different kinds of network conditions here. And maybe also support some kind of offline
Speaker A
viewing.
Speaker A
Mhm. Yeah. Absolutely. So we need to have an offline mode for the app.
Speaker A
Uhhuh. And what about writing the comments or, you know, should we also support that part as offline?
Speaker A
As well, yes, that would be nice. So we should be able to like and write comments in offline mode.
Speaker A
Mhm. Yeah. I think that kind of covers a little bit on the high-level functional requirements. Let me know if I'm missing something and I can add or we can as we go along if you find
Speaker A
something we want to discuss, we can.
Speaker A
Yeah, I think it looks reasonable. Yeah, we can come back if we missed something.
Speaker A
What about, okay, so I think based on this I also want to list out some of the nonfunctional requirements. Scalability. We want to make sure if it reaches 100 million users it's
Speaker A
also performant in a way that users are able to view the list, view the feed items quickly. Performance maybe like in very little latency because we also have to, you know,
Speaker A
upload images, videos. So we want to have a performant system. Also, we want to support offline mode so maybe data efficient.
Speaker A
Mhm.
Speaker A
Synchronization is important because the user can write the messages offline. That will also kind of lead to some of the eviction, you know, other conflict policies that we have to define.
Speaker A
Yeah. And what about the authentication and adding the, you know, friends? So let's leave that out of scope.
Speaker A
Authentication, friends.
Speaker A
Okay. Yeah, I think that kind of gives me a good understanding. With that, let me define some of the high-level contract with the backend, then we can go down into the mobile specifics.
Speaker A
Yeah, absolutely.
Speaker A
Okay. So, for, okay, here we are thinking about a scale of, you know, like a lot of communication driven by the client to the mobile. So I'm assuming maybe HTTP with REST APIs
Speaker A
sounds like a good option.
Speaker A
Mhm. Also, we might want to come back and support real-time notifications. From here what I can see is the user is fetching the list of feeds or posts, is interacting. So
Speaker A
it's mainly the client-side initiation unless there are some updates coming from the backend and maybe for that there are different options. We can come back to it when we have time but there are other options for the client for the
Speaker A
server-initiated server-sent events.
Speaker A
Mhm. Maybe we can also look into WebSockets. gRPC is another good option as well. And what kind of data encoding? I'm assuming there are options like protobuf, XML,
Speaker A
but for now probably JSON is reasonable because we can parse it, read it, also helps us readability.
Speaker A
Yeah, sounds good.
Speaker A
All right. Okay. So let me do some high-level API design first. We want to read or view the feed items. So get v1, let's say we call it feed. It will be, we want to have some kind of
Speaker A
pagination here. So token is x and limit. We also want to limit so that we don't end up making or fetching too many requests, too many items at the same time. The response, can I ask what the token is? Is that
Speaker A
it's more like a pagination token. So we can have, yeah, like a cursor token.
Speaker A
Yes. We should, there are different paginations but I think we should leverage on cursor because it will give us even if there are more changes happening we can always get at the right index and fetch the items from
Speaker A
before or after the cursor elements.
Speaker A
Yeah. So cursor is a better pagination strategy.
Speaker A
So what do you want to use as a cursor ID?
Speaker A
Cursor ID can be some kind of hash ID like abc123 that the backend will give us as an index depending on the
Speaker A
limit of elements we send. So the cursor, the backend will basically index this particular token depending on the rows and columns and will give us this ID. So from there it will always give us the elements either before that
Speaker A
or after that.
Speaker A
All right, sounds good. So how do you distinguish between two types of requests when you want to have a tail load and a front load?
Speaker A
Yeah, we can basically also add some kind of another thing like after and before so then we can know whether we want to go above particular cursor values or below or after. So that can
Speaker A
be part of our pagination metadata where you know...
Speaker A
So I confused it because we have a post HTTP method on top. Um yeah, sorry for that.
Speaker A
No worries. And then we can have this post object which will have additional attributes because I have sent I have sent a like.
Speaker A
Um so it will so user interaction will be like here. So we'll actually return a time stamp from this server. So it will return yes because I can also go back and remove uh the like add so it
Speaker A
can have an updated state and reduced like count. Um and and and the same thing I think we should do for the comment. So we said like let's say the user taps on the comment action it can either open the dialogue or it can
Speaker A
actually deep link to the detail screen and then again the user can make a comment.
Speaker A
So um either the user can comment on a specific uh comment ID or you can also let's say right now we discussed we can just add the comment um in in a list like a flat list not going into the tree
Speaker A
structure. So in that case it can go to the post and then it can do comments and u it will basically have some kind of request object which will have request ID um and then it can have the content or
Speaker A
the text here or it can also be any other kind of text can be image um information and um and and and oh I I I think I forgot got here when we do the author let's say we we always want to have this
Speaker A
API authorized and bearer we can have beer token API what this will do is I don't have to like declare who is the user here because this is my comments it can the back end can know from my uh my
Speaker A
token API or my API key who is the person and it can uh attach my metadata um on the back end um I think this kind of looks uh let me know if I'm missing something but it kind of uh I know like when we do the
Speaker A
image and video it has to do further more processing when uh when it is um so this is for rendering yeah so it will basically give me some kind of URL and I think I again forgot to ask do we know the size of the
Speaker A
image or video or we just for simplicity let's say there is a URL and we can download the image not like handling the big images or big videos because it needs a special handling.
Speaker A
Uh yeah, let's simplify for images and videos. Um let's assume they are already processed and encoded on the back end.
Speaker A
So they should be reasonably small. Um and we don't have to download them in chunks or anything like that.
Speaker A
Thank you. Yep. Yeah. Resly. Yeah. Resably to handle without Yes. Thank you. But yeah like let's say so I think it uh with my post uh data I will also have the image URL or the video URL and then
Speaker A
let's say there is a library that can handle based on the URL and u show it on on the screen. So I think that kind of covers the API high level API contract.
Speaker A
Um because I can see now the list of feed items user interactions infinite we we yeah will go back to infinite scrolling but because it's pagionation it kind of handles uh the scrolling when I reach the uh end the
Speaker A
pageionation metadata will we can check whether I've reached end if not I can keep requesting for more elements.
Speaker A
Mhm. Um I've also kind of handled the text and the image um and and the real time we kind of just touched up on it but yeah I think it kind of looks good.
Speaker A
Mhm. Looks good. Um so with this let me jump into some kind of highle design.
Speaker A
Um for highle design uh this is what I have in mind that we have a client.
Speaker A
Okay. And the client needs to talk to the back end. uh and the back end in our case is let me expand or zoom into what does the back end.
Speaker A
So right now the client is making HTTPS calls to the back end and the back end is uh you know it will start with some kind of uh domain uh resolver domain server resolver but some kind of load
Speaker A
balancer and and from there on it will have some kind of API gateway which will help to route the the requests gateway. Um and then it will have lot of different services on the back end which will actually
Speaker A
we can have some kind of services. So services would be like a feed service post service. We will also need some kind of um comment service because we and user interaction service.
Speaker A
Yeah we don't have to talk in details about the back end implementation but thank you for uh doing this. Yeah.
Speaker A
And I think because of the image, videos and uh audio like videos and images, we will also need some kind of blob storage or S3.
Speaker A
Yep. And that will also kind of help us um you know to uh reduce the latency and scalability because now we can have some kind of CDN which is a content delivery network which will basically be responsible for
Speaker A
providing the images quicker to the client depend irrespective of the geographical location because we have multiple CDNs connected to the S3 servers and let's say if if you want to also support some kind of push notifications we can also have some kind
Speaker A
of FCM uh on on Android or a Apple notifications APN for iOS uh and FCM it's firebased cloud messaging right yes it's a fire it's a third party yes fire cloud uh messaging app provided by the Google and and the back end can
Speaker A
always request um you know the interaction like if you it it wants to send any uh any messages or updates it can use this uh gateway the server to basically pass the information on the back end.
Speaker A
Sorry, quick question here. How does the FCM know what the app it should be conducting?
Speaker A
Yes, we know the user user ID on our back end. But how does the FCM know?
Speaker A
It it it resolves using the device ID from the client. So the way it works is when the client registers initializes the app it also registers to this FCM the third party provider and on on on the call back it gives the token um
Speaker A
token from the FCM and also passes the device ID. Basically the client sends the device ID and and the FCM server returns some kind of token. This token is then being transferred to the our our back end. So every time the back end
Speaker A
wants to uh if there is you know like a push notification that the back end wants to initiate it will use that token and pass it on to the FCM FCM maintain some kind of indexing or the table and
Speaker A
then it knows how to resolve to this particular device ID which is unique and and this is OS based so let's say the client is not active um uh so the mobile is kind of registered the device is
Speaker A
registered to the OxM and then you know like the OS handles um awaking the right application or shows up on the system tray.
Speaker A
Yeah, makes sense. Um, all right. So, I think with this uh let's deep dive into more on the client side of things. Uh, for client we should leverage on u layered architecture because that's um that's easy to handle.
Speaker A
It's scalable. uh we will have data layers, domain layers and we will go in depth on all but the idea is we will we will separate out each different components depending on the responsibility of each layers. We will
Speaker A
also use unidirectional data flow where the state is passed to the UI elements and the events are uh generated from the UI moves up to the layers from domain to data and then from data it makes it to
Speaker A
the network layer. uh we will use uh jetpack compose because it's a new new project and jetpack compose is is a is a preferred way of writing declarative UIs um and has a lot of components like navigation um easily handled we will also depend on
Speaker A
some kind of DI framework um in our there are like Google has provided h and dagger but there are also some third party uh frameworks as well but let's say for simplicity We will just call it EI. So let me zoom into how my client
Speaker A
will look like. Mhm. Yeah. I'd love to see that. Uh-huh. Let me actually I can zoom into this. Okay. Let you don't have to change it. We can do another diagram underneath. It would be handy.
Speaker A
Yeah. Yes. So let me say this will be my client. And for the client we will need um let's say some kind of let's say divide depending on our layer we can say UI layer uh we can have some kind of DI
Speaker A
we can also have some kind of data um I'm kind of abstracting away from the domain because all this UI will talk to the domain layer in form of some case use cases but I don't want to like deep dive
Speaker A
unless we want to go into we if we have time we can go but for now I would love to see the use cases uh okay how many of them do you want to use what would be their names yeah I would love
Speaker A
to see that um I love client side architecture so yeah I usually ask a lot of questions on the in this part okay that's that's perfect let's go into it um so let me then quickly uh demonstrate what my UI would look like
Speaker A
depending on on this we will have this feed items we will call it um news feed E screen or just we can say simply speed screen. Um and each screen will be receiving the data from its own um
Speaker A
stateholder or view model. Uh we will also have something for the details screen. So we can have feed item or we can say details details screen and it will also have its own stakeholder and view model. It just
Speaker A
helps to scale better because you don't want to u have one view model do all um it it helps to like share the responsibility and each is kind of responsible for its own screen and errors loading and um usually on client
Speaker A
we want to like further tail it down to loading error and content. So this is kind of a result class or a silt class and and depending on the state uh it knows what to render for the media we
Speaker A
should the CDN we also need to let's say media loader so we will also have a third party entity not a third party but within the UI we will have component which will be responsible to fetch the uh uh you know the CDN um
Speaker A
the images from the back end because we discussed we will be offloading to some some media loader. Um I think that kind of is a high level UI. Now the way the view model interacts is it does not
Speaker A
inject all the dependencies directly. It will basically inject using some kind of u use cases and the use cases will be let's say we will have get feed items you know uh which will give me uh which will give me list of feed
Speaker A
uh which which will list of post uh we will have our own data objects. Then we will also have um get detail feed items get detail and actually we will observe sorry I would say we can we can actually observe
Speaker A
the changes. So anytime uh the feed items change, we can basically react to the changes directly on the UI and um it it will be the flow of list items because we want to use some kind of cool
Speaker A
routines uh asynchronous library or reactive library under the hood. Uh we can but we can do the get detail items.
Speaker A
By the way, what what sort of li library will you suggest using here? Could you make a specific choice? you there are bunch of different libraries RX Java Cor routines um the are the two uh top ones but RX Java has become more obsolate and
Speaker A
with code cor routines and compose they kind of go so much hand in hand that the Google has kind of u made this co- routines as a preferred asynchronous library but if you have a very legacy app uh you
Speaker A
can do basically they kind of coexist so there is um RX Java to co- routine bridge and other way around so you keep um you know any legacy applications using any of the older frameworks as well.
Speaker A
Yep, sounds good. And here we can have like a uh let's say post. It will just return me the the post. But we also want to observe the comments here. So we can say observe comments for the post. So we can pass the
Speaker A
details. It will take basically the post id and it will give me uh the comments list of comments comment actually and here also it will take the post id and give me the post um it a suspend function we call this is a
Speaker A
this is just like a okay you don't have to like uh think about like code specifics here um yeah but and then again This will be injected because you know we want to use interface pattern that helps in also
Speaker A
writing unit test very easily and and then finally the data layer comes in where the data is all the use cases are being served by the repository. So we will have posts um post repository that will be responsible for basically u
Speaker A
um either any kind of offline messaging or caching so that the client does not have to make API calls every single time the user scrolls or fetches it will be responsible for having some kind of local data source or uh some kind of uh
Speaker A
in-memory store so it can easily um you know update the UI without making before making API calls.
Speaker A
Uh let's make a a concrete decision. What sort of local data source do we want to use? Uh what would be here? Do you want to use inmemory store or database? What is we will use database? We will actually
Speaker A
we can use a combination. Uh we can have both. Um we can have like a data store and an inmemory. So we can have like a layered uh um mechanism here for usually you know like it's called L1 which is in
Speaker A
memory store. So every time let's say we want to render to the UI it will first check do I have anything in my in memory if not it will try to go to um L2 which is called uh database local uh DB store we
Speaker A
can call it. It will be based with SQL or room. There are two options uh which are for Android SQL delight or room and it depending on what how um you know which you are comfortable with. Both have observability. So anytime the data
Speaker A
changes it will basically update. Um but I think we can use some kind of local data store. We can also limit uh how extensive the data store should be because we don't want to have like infinite items being stored at the list
Speaker A
on on the store. we can limit to like maybe 200 megabytes of data. Um we also want want to have some kind of LRU. So only the recently used elements or pages or uh items should be stored and maybe
Speaker A
you know when the user gets offline when the user logs out we should clear um the DB.
Speaker A
So we can we can have some rules around that. And then we can also have um we also want to fetch it from the network.
Speaker A
So we can have some kind of remote uh remote data source. Mhm. Which will be responsible for actually um uh calling the services. So it will have like a network dispatcher. We will have some kind of okay HTTP
Speaker A
uh client which will basically make a service call and this will be responsible for actually connecting to our our back end.
Speaker A
Okay, sounds good. Yeah. Oops. Sorry. We want to I want to save this. So that will be responsible for back end. Um um so let me do like a a high level data flow.
Speaker A
Oh wait a second before you start that I have a question. So um you have just one repository for all all data types or do you want to use like multiple repositories for different data types?
Speaker A
What do you think? What do you prefer? We will use multi. Yes, I think that's a good point. Uh we will have something for user repository. We will also have for the comments. Um and eventually I think for comments we might want to
Speaker A
support offline comments as well. So it will have its own um some kind of u u database as well.
Speaker A
we can have like a comments data store DB so that you know like um so it will be responsible for comments store just because we don't want to like com uh uh again yeah I get it so uh you don't have to
Speaker A
write all data sources for all of them so I just have a question so would you have separate data sources for every repository or can you reuse some for example if you have this network dispatcher that is using okay HTTP Would
Speaker A
you use it only for remote data source of the post repository or you will also use it for remote data source of comments repository? Let's say we will this will be the common uh repository and we can uh we can all of
Speaker A
this repository will be actually when they want to make an API call can be directed from from this.
Speaker A
Oh, so you'll have just one remote data source shared for multiple repositories. We can we can start with that but I think when we when we real uh let's see do I need multiple or one will be okay
Speaker A
probably for now um I I can imagine this repository will be like hey get me the list of elements list of feed items uh update my comments or get me fetch me more comments uh we can have we can we can all bundle
Speaker A
them into one at the moment but it can be easily split out If we need to, we can have like different repositories for each different data source.
Speaker A
Sounds great. Yeah. Okay. And and and I I think even for um so we we should have one DB but we can have different tables. So we can have like a common data object and the same way we
Speaker A
and the reason we want to have like one one table uh one DB basically database so that you know it's easy to like have the foreign keys um if you want to do any kind of joints uh it it just helps
Speaker A
to have u it helps to scale better otherwise you have to u this the the different databases can get out of synchronous and it will be hard to like know you know how to keep them in sync.
Speaker A
So traditionally for I think for a mobile app you definitely it would be yeah easier to have just one relational database. Yeah just one question uh one one small ask before you start the box. Could you add a little
Speaker A
more arrows in here just for the understanding? So your post repository talk is connected to the post uh lo local data source right?
Speaker A
Yes. Yes. So let me actually let's do this connections. So yes, so my post repository will be responsible for the uh post database and it will first check the way it will move is it will always check do I have anything in the store.
Speaker A
If it is it misses then it will check do I have in DB and it will make um it will make a request to the DB. Um and if it it also misses on the DB then it will
Speaker A
basically make a API call to the remote data source and then the remote data source will be responsible to make an API call fetch the data and once the data is back it will start um you know like hydrating it will go to the
Speaker A
repository. the repository will start um you know before making to the UI it will first update the local database um the local database then it will also update my um memory cache and then mhm my arrow is not bad it's not good and
Speaker A
then once it is done it will then go and hydrate the UI through the the use cases so it will first so the repository will then be responsible to go to the items and then from there we will be injecting
Speaker A
into the view model and from view model um so this is how the states would flow from repository all the way to the UI and let's say when I am tapping on a particular um you know uh comment or likes it will
Speaker A
do the same way but in the reverse order so an event will get generated from the UI that UI will again u we will have another use case which will handle uh send comments or send uh open you know
Speaker A
like get details let's Okay, it will come here with with the kind of metadata that it needs like like send or so send likes you know with the post id. It will again go to the repository. Repository will then uh u that is where we can
Speaker A
discuss and deep dive more on how we will first store on the local data store and then basically make a request to the remote data store. So it will be more like an optimistic write on the UI. So
Speaker A
the user will get instant notification instant gratification on like hey I have sent the like and in in once um and then we will process it you know like it will take some couple of milliseconds for the round trip to complete the back end will
Speaker A
say okay I have accepted I got a like and then it will again send the data and if not there is no change we will not show uh we will not update it anything on the UI UI is good but if let's say
Speaker A
something doesn't go well then we can again either notify the user Especially for the comments part, right? If the comments did not make it through, we want to let the user know so they can either post comments again.
Speaker A
Yeah. So, yes, thank you for explaining that. So, I have a question. Where where is the source of truth for your data in this?
Speaker A
The source of truth is always the back end because the client can easily get out of u out of synchronization. Um also also so source of truth is always my back end.
Speaker A
Um and back end is going to be my single source of truth every time. Um and and that is where we want to dive into like how the data synchronization and um data efficiency makes come in. Um because
Speaker A
yeah let's talk about that and also the offline mode. Yes. So let's say for the offline mode we kind of uh let's say now let's say I um I have this application running the user is offline um how will I basically
Speaker A
um you know handle the offline scenario so the way uh let's say I am sending likes or comments it can be scaled to anything we will we will basically create another data object we will call it like a comments
Speaker A
object or user interaction action. So we can actually have another repository which will be user interaction or we we can call it user interaction repository.
Speaker A
Yeah. Okay. Um and user interaction repository. So that will be responsible for saving all the comments or likes. Um and and it will have a new uh data object user interaction which will have some kind of ID that the
Speaker A
the back end will use to basically resolve. Um it will also have the type sent um uh and also we will need some kind of status whether it was pending whether it was um delivered on the back end or um you know delete delivered.
Speaker A
Yes, pending or delivered or updated add. So we can have some we can also have some kind of timestamp here. Um updated at actually let's say let's say we want to save some kind of data object on on our
Speaker A
uh local database. So every time the user is let's say going through the list of feeds it's liking or making comments we will come here and update um the the database and okay so what the status would be for for
Speaker A
example a like uh when you don't have internet connection so for that we will not show to the user we will we will rely on something called optimistic rights. Okay.
Speaker A
So optimistic right we will go ahead and um update the the users like um count or we can also show the like heart you know like it can say have some kind of favorite indication.
Speaker A
Yeah. and and then let's say when the user comes back online uh we will try to like now batch all those requests and send them send the back end in the same order the user interacted with and then
Speaker A
that's where the backend will come in and it will try to resolve um all this um u different requests that come in to the client uh from the client and and once it has resolved it will basically send uh an updates
Speaker A
to the client and uh it and that's where you know uh we will change the status on the user table. Basically we will basically change the status from pending to delivered. We will remove the entry from the user interaction table and then
Speaker A
it will become part of my post table. U so that you know uh we we don't have many different tables lined up. This will be basically this will be just used as a queue mechanism for u u client to
Speaker A
basically send to the back end. Yeah, sounds great. Um yeah, I have another question. Uh let's go back to your diagram and discuss a repository.
Speaker A
So I have question uh my question is what's your approach to error handling and retry logic inside repositories? Uh how are you going to do that?
Speaker A
Yes. So um let's um yes, you're right. we need to handle both of them. The error handling and the retry. For retry, uh usually um you know the HTTP calls when you are creating your HTTP request, it would ask you what kind of u you know
Speaker A
interceptors, what kind of retry logic you want to handle and ideally we want to have we don't want to like flood this back end with lots of requests uh or keep so there is something called exponential exponential backoff. Yep.
Speaker A
Request with retries. Um, so we can we can limit the retries to maybe like three or depending on how crucial a particular action is, you can change and the exponential back off will help basically to uh increase the time or for
Speaker A
every subsequent request or retries it makes. So that let's say it starts with 5 seconds, it will try to make another request at 5 second. then it will exponentially increase to maybe 15 seconds the next retry until we heat the
Speaker A
retry count and if the retry count has been reached then it will stop the client will no longer make that u you know retries. Uh so that's where we want to educate the user with maybe some kind of status update or notification like do
Speaker A
you want to um this this failed you want to try again um uh that is I I think that is how the client should uh because the rate limit otherwise the the client will reach the rate limit on the back end and
Speaker A
eventually the back end will say like I cannot no longer accept the requests and we might miss out on important request other requests that needs to make through the back Then uh for the error scenarios um the it can happen that um
Speaker A
we can have like a network failures right like when the client is making a request maybe uh some kind of 400 errors some kind of 500 errors can come in and at that time again you know we can we
Speaker A
can set those up for the exponential backup or retry but on the UI side we want to let the user know or let's say the Wi-Fi is gone we want to show some kind of banner that the network is not
Speaker A
there um or um uh you know like something went wrong you know try again later so that that can be done on the UI. So we can this is where we can you know use the error uh state from the
Speaker A
from the like 400s or 500 errors can basically get converted into some kind of error notification or banner on the user screen.
Speaker A
Yeah. Uh sounds good. Uh thank you for your explanation. Speaking of UI, I have a question here. So, uh could you tell me about like how do you want to implement navigation between screens? Uh especially when you need to pass uh
Speaker A
certain data between them like a post ID or something else. Yes, I think I kind of missed out. But there is a component called um with compose. I would I would rely on the compose navigation.
Speaker A
Okay. And the way it would do, let's say I'm on the feed screen and when I'm tapping on a particular feed screen, I will pass the post ID to this navigation component and it will internally have a list of uh different screens that I can
Speaker A
navigate to like a router and and it also will maintain my backstack entry. So um uh I will just basically uh pass the post ID to the navigation component.
Speaker A
it will internally resolve uh and and and based on my routing and navigation component it will go to the detail screen. Uh so I will basically uh leverage on the navigation component from compose.
Speaker A
Um yeah sounds reasonable. All right. Uh I think last question for you today. Um how do you decide between a single model app and a multimodel architecture? So let's say our app is evolving. we're adding new features in the future and at
Speaker A
certain points we need to expand to like multimodule architecture on on Android. So how to decide when to do that and um how to actually do that just an overview you don't have to implement it just an overview how do you think about this
Speaker A
problem yes um actually it's it's a on on Android and as especially when we talk about the scale the modular architecture is very important um and from the beginning we will actually start the application with u a simple modular
Speaker A
architecture for example all the UI I can become the part of my feature modules and all the uh the domain and the di the data part can become part of the library module because let's say we want to expand to something else then we
Speaker A
can basically just use a library component. So every every uh feature that we keep on adding can always have these two modules and within internally within the modules we can have like subm modules for data domain API. It also
Speaker A
helps to basically separate the concerns and everybody anybody coming new in the team can easily know hey this is my API which is responsible for networks. The domain is responsible for basically uh interaction with the uh with the UI or
Speaker A
the view models. Mhm. And the presentation logic is also abstracted into um you know a different component which is called a feature component. And this has been like like a gold standard when it comes to many different uh companies like Airbnb,
Speaker A
Netflix, they all want to use this multimodular architecture for scalability, growth and um you know onboarding new new uh people coming on the team and it also helps divide and conquer right so we can always plead a big I just one person cannot cannot
Speaker A
build all these components. So if you have modules they will not interact on each other. We can define the contracts through interfaces and then everybody like we have three people on the team they can easily take somebody can work
Speaker A
on UI somebody can work on data other on domain. So it helps also like split the work um in a in a nicer way. So I would not say like monoliths are the best answers. We should uh unless it's a pet
Speaker A
project, you know, um we should we should for a large scale applications um production applications, we should use multimodular.
Speaker A
Mhm. All right. Uh all right. Uh let's wrap up. Thank you for your time. Um give me a few seconds to finish up my feedback for you. I will I will copy my feedback to the right from the diagram. Here it
Speaker A
is. Uh you don't have to to read it. I will read it to you. So um yeah so first of all you did really well. This is this is gold. So I love our mock interview. I think it is really strong. So my
Speaker A
decision is definitely higher. And I divided my feedback into like four parts. First problem navigation then solution design then technical proficiency and technical communication.
Speaker A
Oops sorry. So let's start with the first. So for problem navigation, so you clearly let the interview. So um you had a clear understanding of on where to go next. So you asked reasonable questions in the beginning on functional
Speaker A
non-functional requirements. You clarified what's out of scope such as authentication, postcreation. You identified and focused on main problems such as offline mode, data synchronization. So we spent a big chunk of our time on those problems. That was really well done. So you have an
Speaker A
extremely good organization of the pro uh problem space. The part that I really enjoyed was that you actually had two two diagrams. The first diagram was sort of like a highlevel design with the client being just a one small box and
Speaker A
with more emphasis on the backend part. What's happening on the back end and how do do they play together. So I like that. And then we have we had like a next like more deeper diagram for client side AR uh architecture.
Speaker A
So uh you had good timing for one hour architecture interview. So for solution design you achieved working solution.
Speaker A
Obviously you suggested using REST API with Corser based penation also mentioned a few alternatives. So that was really good. You addressed uh scalability issues with like using uh client side caching. I think you mentioned CDNs. Uh that was uh really
Speaker A
well done. So you deployed needed architectural patterns such as advanced injection uh you did the repository pattern and also I like that you use this three layered approach uh having like presentation domain and uh data layers for technical proficiency. Uh so
Speaker A
you obviously know common Android frameworks APIs such as room and many others. Uh what can be better here? For example, we could have discussed pre-fetching of the news feed because obviously we have this infinite scrolling list and we can
Speaker A
prefetch some data. Yeah. Also, you obviously know common Android frameworks, jetpack compost, you mention you mentioned cotlin corines, okay, http that was uh really well done. You identified alternative solutions for example even in the beginning you mentioned protobuff and XML and we had
Speaker A
two deep dives. So the first one was about the offline mode and likes and comments in the offline mode. You generally did well. You suggested optimistic updates and also we had a second deep dive in errors and retries
Speaker A
there. You also explained how uh to do everything really well. And for technical communication you did well.
Speaker A
You explained ideas clearly and logically. You made complex topics easily digestible. You shared design choices, train uh trade-offs and responded to my questions and feedback.
Speaker A
So really well done interview. Yeah. Thanks again for your time. Thank you. It was really great Andre like to go through uh this interview. It gives me a lot of confidence as
Topics:system designmobile appFacebook newsfeedpaginationoffline modeREST APIcursor paginationreal-time updatesoptimistic writeslayered architecture
