Architecture

Your single-module app compiles in 45 seconds. You add more features. More screens. More dependencies. Now it takes 3 minutes. Every small change triggers a full rebuild. Worse, any file can import any other file. Your UI layer imports database classes directly. A junior developer bypasses the repository and calls the DAO from a Composable. There are no boundaries. Multi-module architecture fixes both problems. Faster builds (Gradle only recompiles changed modules) and enforced boundaries (modules can only access what they depend on). ...

Your app calls an API. It also reads from a local database. Sometimes the API is down. Sometimes the user has no internet. Where does the data come from? Without a clear answer, your app becomes unpredictable. One screen shows fresh data from the API. Another screen shows stale data from the database. The user sees different information depending on which screen they check first. The repository pattern solves this. It gives your app a single source of truth — one place where data lives. Every screen reads from the same source. ...

Your first Android app works fine with everything in one file. But as the app grows, things fall apart. You add more screens. More API calls. More database queries. Suddenly, one change breaks three unrelated features. This is the architecture problem. And it is the reason most real-world apps follow a structured pattern. In this tutorial, you will learn the three most important architecture patterns for Android: MVVM, MVI, and Clean Architecture. You will understand when to use each one and how they work together. ...

In the previous article, you designed a search engine. Now let us wrap up this series with everything you need to ace a system design interview. This article is a cheat sheet and guide. Bookmark it and review before your interview. The 4-Step Framework Every system design interview follows the same structure. Use this framework to stay organized and cover everything the interviewer expects. 4-Step Framework (40 minutes total): Step 1: Requirements (5 minutes) - Clarify functional requirements (what the system does) - Clarify non-functional requirements (scale, latency, availability) - Define what is IN scope and OUT of scope Step 2: Estimation (5 minutes) - Users, traffic, storage - QPS (queries per second) - Peak vs average load Step 3: High-Level Design (15 minutes) - Architecture diagram - Core components and how they interact - API design - Data model Step 4: Deep Dive (15 minutes) - Interviewer picks 2-3 components to go deeper - Discuss trade-offs, failure modes, scaling - Show your knowledge of specific technologies Step 1: Requirements (5 Minutes) Do not skip this step. Jumping straight to the design is the number one mistake candidates make. ...

In the previous article, you designed a notification system. Now let us tackle one of the most complex systems in computing: a search engine. Search engines like Google index over 100 billion web pages and serve billions of queries per day. We will design a simplified version that covers the core components: crawling, indexing, ranking, and serving. Step 1: Requirements Functional Requirements Crawl the web and discover new pages Index page content for fast retrieval Search by keywords and return ranked results Autocomplete (search suggestions as you type) Return results in under 500ms Non-Functional Requirements Fresh results — new content indexed within hours Relevant results — best pages ranked first Scale to 100 billion indexed pages Handle 10 billion search queries per day High availability — search must always work Step 2: Estimation Indexed pages: 100 billion Average page size: 50 KB (text content after stripping HTML) Total index storage: 100B * 50 KB = 5 PB (raw text) Inverted index size: ~20% of raw text = 1 PB Queries: 10 billion per day QPS: 10B / 86,400 = ~115,000 queries/sec Peak QPS: ~350,000 queries/sec Crawling: New/updated pages per day: 1 billion Crawl rate: 1B / 86,400 = ~11,600 pages/sec Bandwidth: 11,600 * 100 KB (full page) = 1.16 GB/sec Step 3: Web Crawler The crawler discovers and downloads web pages. It is the first stage of the search engine pipeline. ...

In the previous article, you designed a file storage system. Now let us design a notification system that sends push notifications, emails, and SMS messages to millions of users. Every large application needs notifications. Whether it is a new message alert, an order confirmation, or a security warning, the notification system is a critical piece of infrastructure. Step 1: Requirements Functional Requirements Send push notifications (iOS and Android) Send email notifications Send SMS notifications Support different notification types: transactional, marketing, system alerts User preferences: opt-in/opt-out per channel, quiet hours Template-based notifications Delivery tracking and analytics Non-Functional Requirements Soft real-time: transactional notifications within 30 seconds At-least-once delivery (no lost notifications) High throughput: 10 million notifications per minute during peaks No duplicate notifications (deduplication) Scalable to billions of notifications per day Step 2: Estimation Notifications per day: 5 billion Push: 3 billion (60%) Email: 1.5 billion (30%) SMS: 500 million (10%) Peak load: 10 million per minute = ~167,000 per second Per notification: Push: ~500 bytes payload Email: ~5 KB (with HTML template) SMS: ~200 bytes Storage for notification history: 5 billion * 1 KB (average) = 5 TB/day Retention: 30 days = 150 TB Step 3: Notification Types Different notifications have different priorities and requirements. ...

In the previous article, you designed a video streaming service. Now let us design a file storage and sync system like Google Drive, Dropbox, or OneDrive. File storage systems are complex because they need to sync files across multiple devices, handle conflicts, and deduplicate data. Let us break it down. Step 1: Requirements Functional Requirements Upload and download files Sync files across devices (desktop, mobile, web) Share files and folders with other users File versioning (view and restore previous versions) Offline access (work offline, sync when reconnected) Non-Functional Requirements High reliability — files must never be lost Fast sync — changes appear on other devices within seconds Low bandwidth usage — only transfer changed parts of files Support 500 million users with 100 million daily active users Step 2: Estimation Users: 500M total, 100M DAU Storage: Average files per user: 500 files Average file size: 500 KB Total files: 250 billion files Total storage: 500M users * 500 files * 500 KB = 125 PB Daily activity: File uploads/edits: 200M per day File downloads: 500M per day File syncs: 1 billion per day (across devices) Upload bandwidth: 200M uploads/day * average 200 KB change = 40 TB/day upload 40 TB / 86,400 = ~460 MB/sec average upload Metadata: Each file: ~200 bytes of metadata (name, size, hash, version, path) 250 billion files * 200 bytes = 50 TB of metadata Step 3: Block Storage — The Key Insight Instead of storing files as single blobs, split them into fixed-size blocks (typically 4 MB). This is the foundation of how Dropbox and Google Drive work. ...

In the previous article, you designed a news feed. Now let us design a video streaming service like YouTube or Netflix. Video streaming is a complex system with two major pipelines: uploading and processing videos, and streaming them to viewers. Let us break it down step by step. Step 1: Requirements Functional Requirements Upload videos Stream/watch videos Search for videos Like, comment, and subscribe Video recommendations Multiple video quality options (360p, 720p, 1080p, 4K) Non-Functional Requirements High availability — videos should always be watchable Low latency — video should start playing within 2 seconds Smooth playback — no buffering on stable connections Support 1 billion daily active users Support 5 billion video views per day Step 2: Estimation Daily Active Users: 1 billion Video views per day: 5 billion Videos uploaded per day: 500,000 Average video size (original): 500 MB Average video duration: 5 minutes Upload storage per day: 500,000 videos * 500 MB = 250 TB/day (original files) After transcoding (multiple resolutions + formats): Each video -> 5 resolutions * 3 formats = 15 versions Average transcoded version: 100 MB 500,000 * 15 * 100 MB = 750 TB/day (transcoded files) Total storage per day: ~1 PB/day Total storage per year: ~365 PB/year Streaming bandwidth: 5 billion views/day Average bitrate: 5 Mbps (1080p) Average watch time: 3 minutes Total bandwidth: 5B * 5 Mbps * 180 sec = 4.5 exabits/day ~52 Tbps average bandwidth Step 3: Two Main Pipelines A video streaming service has two distinct pipelines that work independently. ...

In the previous article, you designed a chat system. Now let us design a news feed — the home timeline you see on Twitter/X, Instagram, or Facebook. The news feed is one of the most common interview questions. It tests your understanding of fan-out strategies, caching, ranking, and scale. Step 1: Requirements Functional Requirements Users can create posts (text, images, links) Users can follow other users Users see a news feed with posts from people they follow Posts are ranked (not just chronological) Trending topics section Like and comment on posts Non-Functional Requirements News feed loads in under 200ms New posts appear in followers’ feeds within 5 seconds The system supports 500 million daily active users High availability — the feed should always load, even if stale Step 2: Estimation Users: 500 million DAU Posts: Each user creates ~2 posts/day Total: 1 billion posts/day Posts per second: 1B / 86,400 = ~11,600 posts/sec Feed Reads: Each user opens the feed ~10 times/day Total: 5 billion feed reads/day Reads per second: 5B / 86,400 = ~57,870 reads/sec Following: Average user follows 300 people Some users have millions of followers (celebrities) Storage: Average post: 1 KB (text + metadata) 1 billion posts/day * 1 KB = 1 TB/day Per year: ~365 TB Media (images, videos): stored in blob storage + CDN Step 3: The Core Problem — Feed Generation When a user opens their feed, the system must show recent posts from all the people they follow, ranked by relevance. There are two approaches. ...

In the previous article, you designed a URL shortener. Now let us tackle a more complex system: a real-time chat application like WhatsApp or Slack. Chat systems are a favorite in system design interviews because they combine real-time communication, message storage, presence detection, and push notifications. Step 1: Requirements Functional Requirements One-on-one messaging Group messaging (up to 500 members) Online/offline status (presence) Read receipts (message seen) Media sharing (images, files) Push notifications for offline users Message history (persistent storage) Non-Functional Requirements Real-time delivery (< 200ms for online users) Messages must never be lost (durability) Message ordering must be preserved within a conversation The system should support 2 billion users with 50 billion messages per day Step 2: Back-of-the-Envelope Estimation Users: 2 billion total, 500 million daily active users (DAU) Messages: 50 billion messages/day 50B / 86,400 = ~580,000 messages/sec Peak: ~1.5 million messages/sec Message size: Average message: 200 bytes (text) Media messages: ~200 KB (image thumbnail + metadata) Storage per day: Text: 50B * 200 bytes = 10 TB/day Media: assume 5% of messages have media 2.5B * 200 KB = 500 TB/day (media stored in blob storage) Text storage per year: 10 TB * 365 = 3.6 PB Connections: 500M concurrent WebSocket connections Each connection uses ~10 KB of memory Total memory for connections: 5 TB Need thousands of chat servers Step 3: Communication Protocol Why WebSocket? For real-time chat, the server must push messages to clients immediately. HTTP is request-response — the client must ask for new messages. WebSocket provides a persistent, bidirectional connection. ...