mobile-system-design

A Simple Framework For Mobile System Design Interviews (iOS & Android)

This guide provides a framework for approaching mobile system design interviews, specifically for iOS and Android roles. The core idea is that interviewers focus on assessing your thought process and communication skills rather than expecting a perfect, production-ready solution within a limited time. By showcasing your strengths, you enhance your overall evaluation as a candidate.

Join the “Mobile System Design” Discord server for general discussions and feedback.

Disclaimer

This framework is inspired by “Scalable Backend Design” resources. Understanding this guide doesn’t guarantee success. Interview structure varies based on the interviewer’s style. Active dialog is vital – ask clarifying questions and avoid assumptions.

This guide does not reflect the interviewing policies from Google (or any other company).

Interview Process (45–60 min)

• 2–5 min: Introductions
• 5 min: Task definition and requirement gathering
• 10 min: High-level discussion
• 20-30 min: Detailed discussion
• 5 min: Questions for the interviewer

Introductions

Briefly share your relevant experience. Example: “Hi, I’m Alex. I’ve been developing for iOS/Android since 2010, focusing on frameworks and libraries. For the last 2.5 years, I led a team on the XYZ project, covering system design, planning, and technical mentorship.” The purpose is to break the ice and highlight relevant skills.

Defining The Task

The interviewer presents the task, like “Design Twitter Feed.” Determine the task’s scope:

• Client-side Only: Design the app, given a backend and API.
• Client-side + API: Design both the client app and API. (Most Common).
• Client-side + API + Backend: Design the app, API, and backend. (Less Likely). Be transparent if your backend experience is limited. Focus on your mobile expertise and mention your high-level understanding of backend concepts from books, videos, etc.

Gathering Requirements

Categorize requirements into Functional, Non-Functional, and Out-of-Scope. Using “Design Twitter Feed” as an example:

Functional Requirements

Focus on high-value features (3-5).

• Users can scroll through an infinite feed of tweets.
• Users can “like” a tweet.
• Users can view comments for a specific tweet (read-only).

Non-Functional Requirements

These are critical for the product’s overall success.

• Offline support: Users should be able to view cached tweets and interact with them even without internet connectivity.
• Real-time notifications: Notify users of new tweets, likes, and comments.
• Optimal resource usage: Minimize bandwidth, CPU, and battery consumption. Consider network optimization techniques and efficient data handling.

Out of Scope

Exclude features important for a real project but not in the interview scope.

• Login/Authentication
• Sending tweets
• Following/Retweeting
• Analytics

Providing the “Signal”

The interviewer evaluates your thought process. Show them:

• Your assumptions and how you stated them clearly.
• The rationale behind your feature choices.
• Relevant clarifying questions.
• Awareness of trade-offs and potential concerns.

Ask many questions and cover diverse aspects. Use a Breadth-First Search (BFS) approach, then ask the interviewer which area they want to explore in-depth. If they offer a choice, select a topic you know well.

Clarifying Questions

Ask these questions during the task clarification step:

• Do we need to support emerging markets?
  • Consider app size optimization due to low-end devices and expensive data. Prioritize caching and minimize network requests. On Android, look into using app bundles, on iOS investigate app thinning.
• What number of users do we expect?
  • High user count impacts backend load. Discuss Exponential Backoff and API Rate Limiting to prevent unintended DDoS.
• How big is the engineering team?
  • Smaller teams (2-4) require different considerations than larger teams (20-100). Focus on modularity and project structure to enable parallel development. Think about using a monorepo versus a multi-repo strategy.
• What are the target OS versions and device types?
  • This will drive decisions about architectural patterns (e.g. Compose/SwiftUI vs. older view-based systems), available APIs (e.g. for background tasks, data persistence), and necessary compatibility layers.
• Are there any specific performance benchmarks we need to achieve?
  • Understand acceptable latency for feed updates, image loading, and other key interactions. This will influence caching strategies, network optimization, and data serialization techniques.
• What level of data consistency is required?
  • Can we tolerate eventual consistency for likes and comments, or do we need strong consistency? This impacts decisions about offline behavior and data synchronization strategies.
• How frequently is the data updated?
  • If tweets are very frequent, then a pull-based refresh strategy might overwhelm the server. Push notifications or SSE might be more appropriate.
• What are the expected types of media?
  • Image sizes and formats will influence caching and networking strategies. Consider supporting modern formats such as webp or AVIF. Video will require different considerations, such as streaming protocols (HLS, DASH), transcoding, and CDN support.

High-Level Diagram

If the interviewer is satisfied, ask if they want to see a high-level diagram.

Server-side Components:

• Backend: The overall server infrastructure. Focus on client-side concerns.
• Push Provider: Infrastructure for mobile push notifications. Delivers payloads from the backend.
• CDN (Content Delivery Network): Delivers static content (images, videos) to clients efficiently.

Client-side Components:

• API Service: Abstract client-server communication. Provides a clean interface for interacting with the backend. Consider using a library like Retrofit (Android) or Alamofire (iOS).
• Persistence: The single source of truth for data on the device. Data is persisted locally first and then propagated to other components. This enables offline access and reduces network dependency.
• Repository: Mediator between API Service and Persistence. Decouples data sources from the UI.
• Tweet Feed Flow: Components responsible for displaying the scrollable tweet list.
• Tweet Details Flow: Components responsible for displaying a single tweet’s details.
• DI Graph: Dependency injection graph. Enables loose coupling and testability (Dagger/Hilt on Android, Swinject/Typhoon on iOS).
• Image Loader: Loads and caches images (Glide/Coil on Android, SDWebImage/Kingfisher on iOS). Check out Image Loading Strategies Deep Dive.
• Coordinator: Manages navigation and flow logic between Tweet Feed and Tweet Details, decoupling the components. Check out Mobile Navigation Architecture Deep Dive.
• App Module: Executable part of the system that “glues” components together. Responsible for application lifecycle management.
• Analytics Service: A module responsible for collecting and transmitting analytics data, such as user actions and performance metrics.

Providing the “Signal”

The interviewer looks for:

• Ability to present the “big picture” without unnecessary details.
• Identification of major building blocks and their interactions.
• Consideration of app modularity and team collaboration.

Frequently Asked Questions

Why is a high-level diagram necessary? Can I skip it?

Not mandatory, but it has advantages:

• Time management: Quickly outlines the system and raises discussion points.
• Modularity: Each component can be a separate module for team collaboration.
• Best practices: Mirrors backend system design and the C4 model for visualizing architecture (https://c4model.com/).

Still not sure? Ask the interviewer if they want a diagram or prefer to jump into specific components.

Deep Dive: Tweet Feed Flow

The interviewer might focus on a specific component, like “Tweet Feed Flow”. Discuss:

• Architecture patterns: MVP, MVVM, MVI, Clean Architecture, Redux. MVC is generally discouraged. Choose a well-known pattern for easier onboarding.
• Pagination: Essential for infinite scrolling. (See Pagination section).
• Dependency injection: Improves module isolation and testability.
• Image Loading: Discuss low-res placeholders, full-res loading, and scrolling performance.

Components

• Feed API Service: Abstracts the Twitter Feed API client, fetching paginated data. Injected via DI.
• Feed Persistence: Abstracts cached paginated data storage. Injected via DI.
• Remote Mediator: Fetches next/previous page data and saves it to the persistence layer.
• Feed Repository: Consolidates remote and cached responses into a Pager object using the Remote Mediator.
• Pager: Triggers data fetching from the Remote Mediator and exposes an observable stream of paged data to the UI.
• “Tweet Like” and “Tweet Details” use cases: Implement “Like” and “Show Details” operations. Injected via DI.
• Image Loader: Abstracts image loading from the image loading library. Injected via DI.

Providing the “Signal”

The interviewer assesses:

• Familiarity with common MVx patterns.
• Separation of business logic and UI.
• Understanding of dependency injection.
• Ability to design self-contained modules.

Frequently Asked Questions

How much detail should I provide?

No strict rule. Work with the interviewer; ask if they want more detail or to move on. Observe their body language. If they interrupt, stop and ask if they have questions. Collaboration is key.

Why no mention of specific classes (RecyclerView/UICollectionView) or vendors (Room, CoreData, Realm)?

• To keep the guide platform-agnostic. Libraries evolve rapidly. Abstracting functionality is more robust.
• Vendor selection is subjective and based on experience/trends.
• Large companies often build custom stacks.
• Implementation details are widely available online.

What drawing tool should I use?

Excalidraw and Google Drawings are popular choices. Some prefer collaborative editors and verbal discussion. Privacy policies may limit tool choices.

Client Library Design

If the interview task is to design a Library (e.g., Image Loader, Analytics SDK) rather than an App, the focus shifts to the Public API Design.

Providing the “Signal”

The interviewer assesses:

• API Ergonomics: Do you design interfaces that are intuitive and hard to misuse? (e.g., using Result types instead of Exceptions).
• Stability: Do you consider thread safety, idempotency, and graceful error handling?
• Resource Management: Do you ensure the library doesn’t block the main thread or leak memory (avoiding long-lived references to Contexts/Views)?

Check out In-App API Design & Library Architecture Deep Dive for specific patterns (Builder, Singleton, Dependency Injection) and code examples for iOS and Android.

API Design

Cover as much ground as possible. Ask if the interviewer has preferences, or choose an area you know well.

Real-time Notifications

Discuss approaches for real-time updates:

Approach	Pros	Cons	Use Cases
Push Notifications	Easier to implement: Requires less client-side and server-side engineering effort compared to persistent connections. Can wake the app in the background: Allows delivery of updates even when the app is not actively running (within OS limitations). Battery efficient (when used correctly): The OS manages the connection and delivery, optimizing for battery life.	Not 100% reliable: Delivery is not guaranteed due to network conditions, device state, or platform limitations (e.g., Doze mode on Android). May have delays: Delivery latency can vary depending on network conditions and the push notification provider. Relies on 3rd-party service: Dependent on Apple’s APNs (iOS) or Google’s FCM (Android), introducing a point of failure and potential vendor lock-in.	Breaking news alerts, promotional offers, social media mentions, messaging apps (when app is backgrounded).
Short Polling	Simple to implement: Relatively straightforward client-side and server-side logic. No persistent connection: Avoids the complexities of managing and maintaining persistent connections. Compatible with firewalls and proxies: Less likely to be blocked by restrictive network environments. Easy to scale horizontally: The stateless nature of HTTP makes it easier to distribute load across multiple servers. Less expensive (if infrequent): Lower server resource utilization if the polling interval is large. Can be useful for batch updates: Polling can be used to retrieve multiple updates in a single request.	Potential for significant delays: Notification delivery is limited by the polling interval. Overhead from TLS handshake and HTTP headers: Repeated connections introduce significant overhead, especially for small updates. Inefficient bandwidth usage: The client sends requests even when there are no updates available. High server load: Frequent polling can strain server resources, especially with a large number of clients.	Dashboards with low refresh requirements (e.g., status checks every 30s), legacy systems, low-traffic apps.
Long Polling	Instant notifications (almost): Server holds the connection open until an update is available, minimizing latency.	More complex, requires more server resources: Requires more sophisticated server-side logic to manage connections and track updates. Keeps a persistent connection (sort of): Although not a true persistent connection like WebSockets, it simulates one, and managing timeouts is critical. Still introduces some latency: Dependent on server response time even with updates readily available. Susceptible to connection timeouts and interruptions: Requires robust error handling and reconnection logic. Can be more complex to scale: Requires sticky sessions or other mechanisms to ensure that the client connects to the correct server instance.	Web-based chat applications (fallback for WebSockets), simple notification systems where WebSockets are blocked or overkill.
SSE (Server-Sent Events)	Real-time updates with a single connection: Establishes a unidirectional (server-to-client) stream for efficient delivery of updates. Simpler than WebSockets: Easier to implement and manage compared to bidirectional communication protocols. Standard protocol: Leverages standard HTTP protocol, making it easier to integrate with existing infrastructure. Lower overhead than long polling: Avoids the overhead of repeatedly establishing and tearing down connections. Text-based protocol: Easier to debug and inspect compared to binary protocols.	Keeps a persistent connection: Requires server resources to maintain the connection. Unidirectional: Only supports server-to-client communication, making it unsuitable for applications that require frequent client-to-server updates. Limited browser support (older browsers): May require polyfills for older browsers. Connection limits: May be subject to connection limits imposed by browsers or proxies.	Live sports scores, stock tickers, social media news feeds, status updates.
WebSockets	Can transmit binary and text data: Supports both text-based and binary data, enabling a wide range of applications. Full-duplex communication: Enables real-time, bidirectional communication between the client and the server. Lower latency than HTTP polling: Avoids the overhead of repeatedly establishing and tearing down connections. Efficient use of bandwidth: Reduces bandwidth consumption by maintaining a persistent connection.	More complex to set up: Requires more complex server-side and client-side logic compared to HTTP-based protocols. Keeps a persistent connection: Requires server resources to maintain the connection. More complex to scale: Requires specialized infrastructure and techniques to handle a large number of concurrent connections. Firewall issues: May be blocked by firewalls or proxies that do not support WebSockets. Increased security concerns: Requires careful attention to security to prevent attacks such as cross-site scripting (XSS) and denial-of-service (DoS). Higher battery consumption: Maintaining a persistent connection can drain battery life on mobile devices. Harder to debug compared to HTTP: Binary messages can be difficult to inspect.	Real-time chat, multiplayer games, collaborative editing (e.g., Google Docs), live location tracking.

Choose an appropriate approach for the task. For “Design Twitter Feed”, a combination of SSE (primary channel for “like” updates and potentially new tweet notifications if scale allows) and Push Notifications (for clients without active connections or less critical updates) could be suitable. Consider WebSockets for features like real-time chat or live video streaming (if in scope).

Protocols

REST (Representational State Transfer)

Text-based, stateless protocol for CRUD (Create, Read, Update, Delete) operations. Relies heavily on HTTP methods (GET, POST, PUT, DELETE).

Pros

Cons

Easy to learn, understand, and implement: Widely adopted and well-documented, with numerous libraries and frameworks available. Easy to cache using HTTP caching: Leverages built-in HTTP caching mechanisms (e.g., Cache-Control headers) for improved performance. CDNs are very effective with RESTful APIs. Loose coupling: Client and server are independent and can evolve separately as long as the API contract is maintained. Stateless: Each request contains all the information needed for the server to understand and process it, simplifying server-side logic and scalability. Widely supported: Supported by virtually all clients (browsers, mobile apps, etc.) and servers. Human-readable: Text-based messages are easy to debug and inspect.

Less efficient on mobile due to separate connections: Each request requires a new TCP connection (although HTTP/2 mitigates this somewhat with connection multiplexing). Still can contribute to battery drain. Schemaless: Difficult to validate data integrity and format on the client without custom validation logic or external schema definitions (e.g., OpenAPI/Swagger). This also makes refactoring more risky. Stateless: Requires extra functionality to maintain session state, such as cookies or tokens, adding complexity to authentication and authorization. Overhead from metadata and headers: Each request contains contextual metadata and headers, which can add significant overhead, especially for small payloads. Over-fetching/Under-fetching: Clients often receive more data than they need (over-fetching) or need to make multiple requests to retrieve all the required data (under-fetching).

Check out RESTful API Design Deep Dive for a deeper dive into best practices.

GraphQL

A query language for your API and a server-side runtime for executing those queries. Allows clients to request specific data from multiple resources using a single endpoint.

Pros

Cons

Schema-based, typed queries: Clients can verify data integrity and format against a well-defined schema, improving developer experience and reducing errors. Enables introspection of the API. Highly customizable: Clients can request only the specific data they need, reducing the amount of HTTP traffic and improving performance. Eliminates over-fetching. Bi-directional communication with GraphQL Subscriptions (WebSocket-based): Supports real-time updates via WebSockets, enabling features like live feeds and notifications. Strong typing: Allows for compile-time checks, reducing runtime errors. Versioning is less critical: Because clients only request specific data, backend changes are less likely to break existing clients. Developer tools: Excellent tooling for development, including GraphiQL for exploring and testing queries.

More complex backend: Requires a more sophisticated server-side implementation compared to REST, including a GraphQL server and resolvers. “Leaky abstraction” – tight client-backend coupling: Clients become tightly coupled to the backend schema, making it harder to evolve the API without breaking existing clients. Can complicate refactoring. Query performance depends on the slowest service (for federated data): The performance of a query is bound to the performance of the slowest service on the backend, especially in a federated architecture where data is spread across multiple services. N+1 problem can occur without careful consideration. Complexity with caching: HTTP caching is more difficult to implement compared to REST, requiring specialized solutions. Security considerations: Requires careful attention to security to prevent malicious queries and unauthorized access.

WebSocket

Full-duplex communication over a single TCP connection.

Pros

Cons

Real-time, bi-directional communication: Enables continuous communication between the client and the server, ideal for applications that require low-latency updates. Supports text and binary data: Can transmit both text-based and binary data, making it versatile for various use cases. Low latency: Reduces latency by maintaining a persistent connection, avoiding the overhead of repeatedly establishing and tearing down connections. Efficient bandwidth usage: Reduces bandwidth consumption by only sending data when there are updates.

Requires maintaining an active connection: Requires server resources to maintain the connection, potentially leading to scalability challenges. Schemaless: Difficult to validate data integrity and format on the client without custom validation logic. This can also make debugging more difficult. Limited number of active connections per server (65k limitation is theoretical and OS-dependent): The actual limit depends on the server operating system and hardware, but managing a very high number of concurrent connections can be challenging. Connection pooling and proper resource allocation are crucial. More complex to implement than HTTP polling or SSE: Requires more sophisticated client-side and server-side logic. Stateful: The server needs to maintain state about each client connection, which can complicate scaling and fault tolerance.

Learn more:

• WebSocket Tutorial - How WebSockets Work

gRPC (gRPC Remote Procedure Calls)

A modern open source high performance Remote Procedure Call (RPC) framework that runs on top of HTTP/2. Supports bi-directional streaming using a single physical connection.

Pros

Cons

Lightweight binary messages (smaller than text-based): Uses Protocol Buffers (Protobuf) for message serialization, resulting in smaller message sizes and improved performance. Schema-based: Built-in code generation with Protobuf, ensuring type safety and reducing errors. Supports event-driven architecture: Provides support for server-side streaming, client-side streaming, and bi-directional streaming, enabling a wide range of use cases. Multiple parallel requests: Leverages HTTP/2 multiplexing to send multiple requests over a single connection. High performance: Optimized for low latency and high throughput. Strong typing: Provides strong typing for both requests and responses, reducing runtime errors. Good performance on unreliable networks: Protocol Buffers are designed to be resilient to data corruption and network disruptions.

Limited browser support: Requires gRPC-Web for browser clients, which adds complexity. While support has improved, it’s still not as seamless as REST or GraphQL. Non-human-readable format: Binary messages are difficult to debug and inspect without specialized tools. Steeper learning curve: Requires familiarity with Protocol Buffers and gRPC concepts. Increased complexity compared to REST: More complex to set up and configure compared to REST. Heavier on client: The client library required for gRPC is generally larger compared to REST, which may impact app size. Not as widely understood as REST: REST is much more widely understood, and developers are more likely to be familiar with it.

MQTT (Message Queuing Telemetry Transport)

A lightweight, publish-subscribe network protocol that transports messages between devices. Often used for IoT applications but can be suitable for mobile in specific scenarios.

Pros

Cons

Lightweight: Minimal bandwidth usage and low overhead, ideal for constrained networks. Publish-Subscribe: Decouples message producers and consumers. Real-time communication: Low latency and quick message delivery. QoS Levels: Provides different Quality of Service (QoS) levels to ensure message delivery based on importance (at most once, at least once, exactly once).

Binary protocol: Difficult to debug and inspect. Not as widely used as HTTP-based protocols: Less mature ecosystem compared to REST, GraphQL, and WebSockets. Stateful: Requires managing client connections and subscriptions. Security Considerations: Requires careful configuration to secure the MQTT broker and client connections. Broker Dependency: Relies on a central MQTT broker for message routing, which can be a single point of failure.

Select an appropriate protocol. REST is suitable for “Design Twitter Feed” due to its simplicity for many of the initial tasks, though consider GraphQL for more complex data fetching requirements in the future. For truly real-time scenarios (if in scope), explore WebSockets or SSE. gRPC may be overkill for the initial feature set but beneficial if significant performance improvements are needed with more complex features. Consider MQTT only if you specifically need to interact with IoT devices or have very constrained network conditions.

Pagination

Essential for endpoints returning lists. Prevents excessive network and memory usage.

Types of Pagination

Strategy	Pros	Cons
Offset Pagination (also known as Limit-Offset Pagination)	Easy to implement: Parameters can be passed directly to a SQL query (e.g., SELECT * FROM tweets LIMIT 20 OFFSET 100). Stateless on the server: The server doesn’t need to maintain any state about previous requests. Simple to understand: Intuitive for both developers and API consumers.	Poor performance with large offsets: The database needs to scan through a large number of rows before returning the requested page, leading to increased latency, especially for large tables. Inconsistent when adding/deleting rows (Page Drift): If new items are inserted or deleted before the requested offset, the same item might appear on multiple pages, or items might be skipped entirely. This is also known as the “missing item” or “duplicate item” problem. Not suitable for real-time feeds: Page drift makes it unsuitable for rapidly changing datasets. Vulnerable to Parameter Manipulation: Clients can easily manipulate the offset parameter, potentially accessing unauthorized data or causing performance issues.
Keyset Pagination (also known as Seek Method or Time-Based Pagination)	Translates easily to SQL: Can be implemented efficiently using WHERE clauses in SQL (e.g., SELECT * FROM tweets WHERE created_at > '2021-05-25T00:00:00' ORDER BY created_at ASC LIMIT 20). Good performance with large datasets: Avoids the performance issues of offset pagination, as the database can use an index on the ordering field. Stateless on the server: The server doesn’t need to maintain any state about previous requests. More resilient to insertions: Insertions after the “after” value won’t cause items to be skipped or duplicated (though insertions before will affect the total number of pages).	“Leaky abstraction” – pagination aware of the database: The API exposes details about the underlying data storage (the ordering field), increasing the risk of breaking changes if the database schema changes. API consumers need to know what field to paginate on. Only works on fields with natural ordering (timestamps, IDs, etc.): Requires a field that can be used to consistently order the results. Doesn’t work well if there’s no clear ordering. Can have issues with ties: If multiple items have the same value for the ordering field, the pagination might not be consistent (addressed using compound keyset pagination). Sensitive to data modifications: Deletions of items within a page can still cause issues. Less flexible for random access: Difficult to jump to a specific page without iterating through all the preceding pages.
Cursor/Seek Pagination (also known as Token-Based Pagination)	Decouples pagination from SQL: The API doesn’t expose any details about the underlying data storage or ordering. Consistent ordering when inserting/deleting new items: More robust to data modifications than offset pagination. More flexible: Can support various ordering criteria and complex queries. Hides implementation details: Clients don’t need to know which field is being used for sorting/pagination.	More complex backend: Requires generating and managing cursors, which involves encoding and encrypting the pagination state. Also requires decoding and validating the cursor on subsequent requests. Does not work well if cursors expire or become invalid: Requires careful management of cursor lifetime and invalidation. Deletions of all items between the ‘after_id’ and the next item can invalidate the cursor. Still potentially sensitive to item deletions: If items are deleted and IDs re-used. Less transparent: Can be harder to debug issues, as the cursor is an opaque token. Not easily bookmarkable: Cursors might expire, making bookmarking difficult.
Page Number Pagination	Easy for users to understand: Intuitive for users familiar with traditional pagination. Simple to implement (initially): Can be implemented using offset pagination on the backend.	Inherits all the cons of offset pagination: Poor performance with large page numbers, page drift issues, etc. Not suitable for infinite scrolling: Doesn’t scale well for applications with a large number of pages. Not suitable for real-time data: Page drift issues.

Choose an approach. Cursor Pagination is suitable for “Design Twitter Feed” as it decouples pagination from the underlying data store and can handle insertions/deletions reasonably well. However, consider the complexity of implementation. If the dataset doesn’t change frequently and the API is read-heavy, Keyset pagination might be a simpler and more performant alternative. Offset pagination is generally discouraged unless the dataset is small and doesn’t change frequently.

Example API request:

GET /v1/feed?after_id=p1234xzy&limit=20
Authorization: Bearer <token>
{
  "data": {
    "items": [
      {
        "id": "t123",
        "author_id": "a123",
        "title": "Title",
        "description": "Description",
        "likes": 12345,
        "comments": 10,
        "attachments": {
          "media": [
            {
              "image_url": "https://static.cdn.com/image1234.webp",
              "thumb_url": "https://static.cdn.com/thumb1234.webp"
            },
            ...
          ]
        },
        "created_at": "2021-05-25T17:59:59.000Z"
      },
      ...
    ]
  },
  "cursor": {
    "count": 20,
    "next_id": "p1235xzy",
    "prev_id": null
  }
}

Additional Information

• Evolving API Pagination at Slack
• Everything You Need to Know About API Pagination

Check out Mobile Pagination Strategies & Deep Dive for more details.

Mention HTTP authentication (Authorization header, 401 Unauthorized) and Rate-Limiting (429 Too Many Requests). Keep it brief and simple. Also, discuss potential API versioning strategies if the pagination scheme needs to be updated in the future.

Providing the “Signal”

The interviewer assesses:

• Awareness of network challenges and expensive traffic.
• Familiarity with communication protocols.
• Understanding of RESTful API design.
• Familiarity with authentication and security.
• Understanding of network error handling and rate-limiting.
• Understanding of the trade-offs associated with different pagination strategies.
• Ability to choose a pagination strategy that is appropriate for the specific use case.

Data Storage

Data Storage Options

Local device storage options:

Option	Pros	Cons
Key-Value Storage (UserDefaults/SharedPreferences/Property List/MMKV)	Easy to use built-in API: Simple APIs for storing and retrieving data. Fast for simple operations: Efficient for small amounts of data. Low overhead: Minimal memory footprint.	Insecure: Data is stored in plain text (use EncryptedSharedPreferences on Android, third-party wrappers or Keychain on iOS for sensitive data). Not for large data: Performance degrades significantly with large datasets. No schema or querying: Limited querying capabilities. No data integrity constraints. No data migration: Difficult to manage schema changes. Poor performance for complex operations: Inefficient for complex data structures or operations. Not ACID compliant: No guarantee of atomicity, consistency, isolation, or durability.
Database/ORM (SQLite/Room/Core Data/Realm/ObjectBox)	Object-relational mapping (ORM): Simplifies data access and manipulation using object-oriented paradigms. Schema and querying: Supports structured data with defined schemas and powerful querying capabilities using SQL or ORM-specific query languages. Data migration: Provides mechanisms for managing schema changes and data migration. ACID properties: Guarantees atomicity, consistency, isolation, and durability. Efficient for complex operations: Optimized for complex data structures and operations.	More complex setup: Requires defining schemas, setting up database connections, and managing ORM configurations. Potentially Insecure: (use SQLCipher or other encryption libraries, properly configured) Bigger memory footprint: Database files can consume significant storage space. Performance overhead: ORM can introduce performance overhead compared to raw SQL queries. Steeper learning curve: Requires familiarity with SQL or ORM concepts.
Custom/Binary (DataStore/NSCoding/Codable/Protocol Buffers)	Highly customizable: Allows fine-grained control over data serialization and storage. Performant: Can be optimized for specific data structures and operations. Potentially smaller footprint: If you carefully control serialization and avoid ORM overhead.	No schema/migration: Requires manual management of schema changes and data migration. Lots of manual effort: Requires writing custom serialization and deserialization code. Increased complexity: Requires a deep understanding of data structures and serialization techniques. Error-prone: Serialization and deserialization code can be complex and prone to errors. Harder to debug: Binary formats are difficult to inspect and debug without specialized tools.
On-Device Secure Storage (Keystore/Key Chain/Android Biometrics)	Secure: Provides hardware-backed or OS-level encryption for sensitive data. Protects against unauthorized access and data breaches. Integrates with device security: Leverages device-level security features such as biometrics and PIN/password authentication.	Not optimized for general storage: Designed for storing small amounts of sensitive data such as encryption keys and user credentials. Encryption/decryption overhead: Can introduce performance overhead for encryption and decryption operations. No schema/migration: Limited querying capabilities. Difficult to manage schema changes. Complex API: Can be complex to use correctly. Limited storage: Has restrictions on the amount of storage space available. User Dependency: Reliant on the user configuring a lockscreen.
File Storage (Internal/External Storage)	Simple to implement. Suitable for storing large, unstructured data.	No schema. Limited querying capabilities. Can be slow for random access. Requires careful management of file paths and permissions.

Storage Location

• Internal: Sandboxed, private to the app, and not readable by other apps (with few exceptions). Data is deleted when the app is uninstalled.
• External: Publicly visible and accessible to other apps (subject to permissions). Data persists even after the app is uninstalled. Generally discouraged for sensitive data.
• Media/Scoped: A restricted subset of external storage specifically for media files. Provides enhanced privacy and security compared to traditional external storage. Requires proper permissions and follows specific access patterns.

Storage Type

• Documents (Automatically Backed Up): User-generated data that cannot be easily re-generated (e.g., user profiles, documents, settings). Automatically backed up to cloud storage (e.g., iCloud, Google Drive) unless explicitly excluded.
• Cache: Regeneratable data that can be downloaded again or recreated (e.g., downloaded images, cached API responses). Can be deleted by the system to free up space. Should not contain critical data.
• Temp: Temporary data that is only used for a short period and should be deleted when no longer needed (e.g., temporary files created during processing). Not backed up and can be deleted by the system at any time.

Best Practices

• Store as little sensitive data as possible.
• Use encrypted storage for sensitive data (e.g., EncryptedSharedPreferences, Keychain, or SQLCipher).
• Prevent uncontrolled storage growth. Implement cache cleanup policies and manage file sizes.
• Use appropriate storage locations based on data privacy requirements (internal vs. external storage).
• Consider data backup and restore strategies for user-generated data.
• Use modern data storage APIs (e.g., DataStore on Android) for improved performance and security.
• Avoid storing secrets or API keys directly in the code or configuration files.
• Implement proper error handling and logging for data storage operations.
• Test data storage logic thoroughly to ensure data integrity and prevent data loss.

Approach

Select an approach and discuss pros/cons. For “Design Twitter Feed”:

Feed Pagination Table

Use Room (Android) or CoreData (iOS) for storing paginated feed data. The schema could look like this:

// Kotlin (Android - Room)
@Entity(tableName = "feed")
data class FeedItem(
    @PrimaryKey val itemId: String,
    val authorId: String,
    val title: String,
    val description: String,
    val likes: Int,
    val comments: Int,
    val attachments: String, // comma separated list of URLs or JSON
    val createdAt: Date,
    val cursorNextId: String?,
    val cursorPrevId: String?
)

// Swift (iOS - Core Data)
// Add attributes for: itemID, authorID, title, description, likes, comments, 
// attachments, createdAt, cursorNextId, cursorPrevId

• Limit the total number of entries (e.g., 500) to control local storage size. Implement a Least Recently Used (LRU) eviction policy to remove older items.
• Flatten attachments into a comma-separated list of URLs or store them as JSON within a text field. Alternatively, create a separate attachments table and join it with the feed table on itemId for better normalization.
• Store cursorNextId and cursorPrevId with each item to simplify paged navigation. Use nullable types for the cursor IDs.

Attachments Storage

• Store attachments (images, videos) as files in Internal Cached storage.
• Use attachment URLs as cache keys. Implement an ImageLoader library like Coil (Android) or Kingfisher (iOS) to manage downloading, caching, and displaying images.
• Delete attachments when the corresponding feed items are deleted from the feed table. Implement a mechanism for deleting orphaned attachments.
• Limit the cache size (e.g., 200-400 MB) to prevent excessive storage usage. Use an LRU cache eviction policy to remove less frequently used attachments.

For sensitive media data (e.g., private accounts), selectively encrypt image files using encryption keys stored in the Keystore/KeyChain. Use Android Biometrics API or Touch ID/Face ID on iOS for user authentication to access the encrypted data.

Providing the “Signal”

The interviewer assesses:

• Awareness of mobile storage types, security, limitations, and compatibility.
• Ability to design a storage solution for common scenarios, considering performance, security, and scalability.
• Understanding of data modeling and database design principles.
• Familiarity with data persistence libraries and frameworks on Android and iOS.
• Awareness of data encryption and secure storage practices.
• Understanding of cache management and eviction policies.

Additional Topics

Major Concerns For Mobile Development

Key concerns to keep in mind:

• User Data Privacy: Leaks can damage business reputation and result in legal penalties. Ensure compliance with privacy regulations such as GDPR and CCPA.
• Security: Protect against reverse engineering (more important for Android), data breaches, and unauthorized access. Implement security best practices such as data encryption, secure authentication, and authorization.
• Target Platform Changes: New OS releases may limit functionality and tighten privacy. Stay up-to-date with platform changes and adapt the app accordingly. Use compatibility layers or conditional compilation to handle differences between OS versions.
• Non-reversibility of released products: Assume releases are final. Use staged rollouts and server-side feature flags to safely deploy new features and minimize the impact of bugs.
• Performance/Stability:
  • Metered data usage: Cellular data can be expensive. Optimize network requests and minimize data transfer. Use data compression techniques.
  • Bandwidth usage: Constant radio usage drains battery. Batch network requests and use efficient network protocols.
  • CPU usage: High computation drains battery and causes overheating. Optimize algorithms and use background threads for computationally intensive tasks.
  • Memory Usage: High usage increases the risk of background termination. Use memory profiling tools to identify and fix memory leaks.
  • Startup Time: Slow startup creates a poor user experience. Optimize app initialization and lazy-load resources.
  • Crashers/ANRs: UI freezes and crashes lead to poor app ratings. Implement crash reporting and use error tracking tools to identify and fix bugs.
• Battery Consumption: Minimize battery drain by optimizing network requests, CPU usage, and background processing. Use battery profiling tools to identify and fix battery-related issues.
• Geo-Location Usage:
  • Don’t compromise privacy with location services.
  • Prefer the lowest possible accuracy. Request increased accuracy progressively.
  • Provide a rationale before requesting location permissions. Use coarse location when fine location is not required. Obfuscate precise locations if possible.
• 3rd-Party SDKs Usage:
  • SDKs can cause performance regressions, security vulnerabilities, and outages.
  • Guard each SDK with a feature flag.
  • Use A/B testing or staged rollout for new SDK integrations.
  • Have a long-term support and upgrade plan. Regularly review and update SDKs to address security vulnerabilities and performance issues.
• App Responsiveness: Ensure the app remains responsive to user input even when performing complex tasks. Use background threads and asynchronous operations to avoid blocking the main thread.
• Testing on Real Devices: Test the app on a variety of real devices to ensure compatibility and performance. Use cloud-based device testing services to access a wide range of devices.
• Licensing and Legal Compliance: Comply with all applicable licensing terms and legal regulations, including open source licenses, privacy policies, and data security laws.

Privacy & Security

Privacy and security should be a central consideration throughout the entire development lifecycle, not an afterthought.

• Minimize user data collection: Only collect data that is absolutely necessary for the functionality of the app.
  • Avoid device identifiers (use resettable, pseudo-anonymous IDs). Consider using Instance IDs instead.
  • Anonymize collected data whenever possible. Aggregate data and remove personally identifiable information (PII).
  • Explain what data you are collecting, how it is used, and who it is shared with, in easy to understand terms.
  • Provide users with transparency and control over their data. Allow users to access, modify, and delete their data.
  • Implement data retention policies to ensure that data is only stored for as long as it is needed.
• Minimize permission usage: Request only the permissions that are necessary for the app’s functionality.
  • Be prepared for permission denials and respect the user’s choice. Handle permission denials gracefully and provide alternative functionality if possible.
  • Be prepared for auto-reset permissions. Implement a mechanism for requesting permissions again if they are auto-reset by the system.
  • Be prepared for app hibernation of unused apps.
  • Delegate functionality to system apps (Camera, Photo Picker, File Manager) to reduce the need for permissions.
• Secure Data Storage:
  • Assume on-device storage is not secure, even when using KeyStore/KeyChain functionality. Implement encryption to protect sensitive data.
    • Encrypt all sensitive data at rest using strong encryption algorithms.
    • Store encryption keys securely in the KeyStore/KeyChain or a hardware security module (HSM).
    • Use secure data storage APIs such as EncryptedSharedPreferences on Android and the Keychain on iOS.
    • Implement proper access controls to restrict access to sensitive data.
  • Assume backend storage is also not secure.
    • Use end-to-end encryption to protect data in transit and at rest. Implement server-side encryption to protect data stored in the backend.
    • Use secure communication protocols such as HTTPS.
    • Implement proper authentication and authorization mechanisms to restrict access to backend resources.
• Secure Communication:
  • Use HTTPS for all network communication.
  • Validate server certificates to prevent man-in-the-middle attacks.
  • Implement proper authentication and authorization mechanisms.
  • Use secure data transfer protocols.
• Code Security:
  • Protect against reverse engineering by obfuscating the code and using anti-tampering techniques.
  • Validate user input to prevent injection attacks.
  • Use secure coding practices to avoid common security vulnerabilities.
  • Perform regular security audits and penetration testing.
• Privacy by Design:
  • Implement privacy considerations at every stage of the development process.
  • Conduct a Data Protection Impact Assessment (DPIA) to identify and mitigate privacy risks.
  • Use privacy-enhancing technologies (PETs) such as differential privacy and homomorphic encryption.
• Regular Security Updates:
  • Stay up-to-date with the latest security vulnerabilities and patches.
  • Regularly update dependencies and third-party libraries.
  • Implement a security incident response plan.
• Privacy Compliance:
  • Comply with all applicable privacy regulations, such as GDPR and CCPA.
  • Obtain user consent before collecting or processing personal data.
  • Provide users with the right to access, modify, and delete their data.
  • Implement data breach notification procedures.
• Transparency and User Education:
  • Assume platform security/privacy rules will change. Control critical functionality with remote feature flags to quickly adapt to new regulations.
  • User perception of security is crucial. Discuss how you would educate users about data collection, storage, and transmission.
    • Be transparent about data collection practices.
    • Provide users with clear and concise information about how their data is used.
    • Educate users about security threats and best practices.
    • Implement a user-friendly privacy policy.

Cloud vs On-Device

Choose between running functionality on a device or in the cloud. Especially relevant for On-Device AI, Machine Learning, and complex processing.

Cloud Execution

Pros

Cons

Device-independent: Customers are not limited by device capabilities (CPU, GPU, memory). Runs consistently across all devices. Better usage of client system resources: Offloads intensive computation, saving device battery and preventing overheating. Fast pace of changes: Updates and improvements can be deployed server-side without requiring app updates, enabling rapid iteration. A/B testing and experimentation are easier. Bigger computational resources: Access to virtually unlimited compute power, enabling complex tasks such as large-scale data processing and complex AI models. Better security: Server-side code is generally more secure than client-side code, as it is not exposed to the user. Easier to protect against reverse engineering and tampering. Secure environments and more sophisticated security tools are usually available. Easier analytics and offline data analysis: Centralized data collection enables comprehensive analytics and insights into user behavior and app performance. Easier to perform batch processing and machine learning on aggregated data. Simplified development: Can simplify mobile development by offloading complex logic and processing to the cloud. Developers can focus on building the user interface and user experience.

Increased Latency: Requires network communication, which can introduce latency and negatively impact the user experience. Can be a major problem for real-time or interactive applications. Network Dependency: Requires a reliable network connection. Users may not be able to access certain features when they are offline or have a poor network connection. Cost: Cloud resources can be expensive, especially for computationally intensive tasks. Need to carefully manage cloud costs and optimize resource utilization. Security Risks: Requires careful attention to security to protect data in transit and at rest. Data breaches can have serious consequences. Compliance Challenges: May be subject to data privacy regulations such as GDPR and CCPA. Requires careful consideration of data residency and data transfer requirements.

On-Device Execution

Pros

Cons

Better privacy: Data does not leave the user’s device, providing enhanced privacy and security. Reduces the risk of data breaches and unauthorized access. No data is transmitted over the network. Real-time functionality: Certain operations can run much faster on a user’s device, providing a more responsive and interactive user experience. Suitable for applications that require low latency. Lower bandwidth usage: Reduces bandwidth consumption by avoiding the need to send data over the network. Can be important for users with limited data plans or poor network connections. Offline functionality: Allows users to access certain features even when they are offline. Improves the user experience in areas with poor network coverage. Lower backend usage: Reduces the load on the backend servers, potentially saving costs. Distributes the processing load across all client devices. No server costs for computations performed on-device. Reduced dependency on external services: Makes the application more resilient to outages or disruptions of external services.

Device Limitations: Performance is limited by the device’s CPU, GPU, and memory. May not be suitable for computationally intensive tasks or large datasets. Inconsistent Performance: Performance can vary significantly depending on the device. Requires careful optimization to ensure consistent performance across a range of devices. Larger App Size: Can increase the app size due to the inclusion of machine learning models or other large libraries. Difficult to Update: Requires app updates to deploy new features or bug fixes. Can be difficult to ensure that all users are running the latest version of the app. Security Risks: Client-side code can be more vulnerable to reverse engineering and tampering. Requires careful attention to security to protect sensitive data. Battery Consumption: Can drain battery life, especially for computationally intensive tasks.

Things you should never run on a device:

• New “resource” creation (sensitive): Generating coupons, tickets, promo codes, or other sensitive resources should always be done server-side to prevent fraud.
• Transactions and Payment verification: Never process payment information directly on the device. Delegate to a 3rd-party SDK (e.g., Stripe, Braintree) or redirect the user to a secure payment gateway. Sensitive financial calculations should be performed on the server.
• Complex Business Logic or sensitive Algorithms: Sensitive algorithms, user authentication, or core business rules should be kept on the server for security and control. This protects valuable IP and allows for updates without app releases.

Offline and Opportunistic State

Offline state ensures app usability without a network connection:

• User can like/comment/delete tweets offline.
• UI updates “opportunistically” assuming requests will be sent when online.
• App displays cached results.
• App notifies users about its Offline State, and any pending actions.
• State changes are batched and sent when the network goes back online.

Check out Offline-First Architecture & Data Synchronization Deep Dive for a deep dive into synchronization strategies and conflict resolution.

Request de-duplication

Ensure retrying requests won’t create duplicates on the server (idempotence). Use unique client-side generated request IDs and server-side de-duplication. The server should store a record of processed request IDs for a certain period.

Use the Idempotency-Key HTTP header to ensure a client can safely retry a request without accidentally performing the same operation twice. The client generates a unique key for each request and includes it in the header. If the server receives the same key again, it knows that the request has already been processed and can return the previous response.

Example (Kotlin):

// Client-side request
val idempotencyKey = UUID.randomUUID().toString()
val request = Request.Builder()
    .url("https://example.com/api/like")
    .header("Idempotency-Key", idempotencyKey)
    .post(requestBody)
    .build()

Synching Local and Remote States

Handle state synchronization across multiple devices. Implementing conflict resolution is crucial.

Strategy	Pros	Cons
Local Conflict Resolution (Last Write Wins with Timestamps - often NOT recommended)	Easy to implement (but often incorrect).	Insecure - gives a local device authority over the backend. Fails if multiple devices send updates simultaneously (the last update “wins,” potentially losing data). Requires app update for merging logic changes. Can lead to data loss and inconsistencies.
Remote Conflict Resolution (Recommended)	Moves conflict resolution authority to the backend. Does not require client updates for resolution logic. More reliable and consistent data synchronization.	More complex backend implementation. Potentially overwrites local, un-synced changes on the client, requiring careful UX design to manage.

Conflict Resolution Strategies (on the server, using Remote Conflict Resolution):

• Last Write Wins with Timestamps (Not recommended in most cases): The server simply accepts the latest update based on the timestamp. This is the simplest approach, but it can lead to data loss if clocks are not synchronized or if updates are received out of order.
• Conflict Detection and Resolution UI: The server detects a conflict and returns an error to the client, prompting the user to manually resolve the conflict through a UI. This approach provides the most control over conflict resolution but can be cumbersome for the user.
• Operational Transformation (OT): A more sophisticated approach that transforms operations based on the history of changes. This allows for concurrent edits to be merged seamlessly. OT is more complex to implement but provides a better user experience.
• Conflict-Free Replicated Data Types (CRDTs): Data structures that are designed to be merged automatically without conflicts. CRDTs are a good choice for applications where data consistency is critical.

More Information

Offline functionality for Trello’s mobile applications: Airplane Mode: Enabling Trello Mobile Offline

Caching

Caching is essential for offline support, reducing network usage, and improving performance. It involves storing data in memory (for immediate access) or on disk (for persistence).

Check out Caching Strategies Deep Dive for details on strategies (Read-Through, Stale-While-Revalidate), eviction policies, and security.

Quality Of Service (QoS)

Implementing Quality of Service (QoS) for network operations is critical for providing a smooth user experience while conserving device resources. It involves prioritizing network requests based on their importance (User-Critical vs Background).

Check out Quality of Service Deep Dive for details on concurrency limits, request prioritization, and power management.

Resumable Uploads (Chunked Uploads)

Resumable uploads break down large files into smaller chunks, allowing the upload to be paused and resumed. This improves reliability on unstable networks.

Check out Resumable Uploads Deep Dive for the initialization process, chunk appending, and advantages/disadvantages.

Prefetching

Prefetching proactively fetches data before it is explicitly requested (e.g., preloading the next page of a feed). This reduces latency and improves UX but consumes more resources.

Check out Prefetching Deep Dive for types of prefetching, implementation strategies, and how to mitigate negative impacts.

Conclusion

Navigating system design interviews can feel like an overwhelming task. Remember that there’s inherent randomness – the process can differ significantly across companies and even between interviewers within the same company. The key is to focus on what you can control and learn from what you can’t.

Things You Can Control:

• Your Mindset: Approach each interview with a positive and curious attitude. Be enthusiastic about solving the problem and demonstrate a willingness to learn. Be respectful and collaborative, even under pressure. A good attitude leaves a lasting impression.
• Your Preparation: Thorough preparation is your strongest weapon. Practice mock interviews with peers, mentors, or online services. The more you practice, the more comfortable and confident you’ll become.
• Your Knowledge Base: Continuously expand your knowledge of mobile technologies, architectural patterns, and design principles. Stay updated with the latest trends and best practices in iOS and Android development.
  • Immerse yourself in open-source projects: iOS, Android
  • Curated List of Real-world Design Blog Posts
• How you articulate your thought process: Clearly and concisely explain your reasoning behind design choices, and be prepared to justify your decisions with evidence and trade-offs. Walk the interviewer through your process step-by-step.
• Your Resume: Craft a compelling resume that highlights your accomplishments and demonstrates the impact you’ve made in your previous roles. Quantify your achievements whenever possible. Tailor your resume to match the specific requirements of the position you’re applying for.

Things Beyond Your Control:

• The Interviewer’s Style and Bias: You might encounter interviewers with different personalities, preferences, or even unconscious biases. Focus on presenting your best self and don’t take any perceived negativity personally.
• The Competition: There might be other highly qualified candidates with more experience or skills. Focus on showcasing your unique strengths and value proposition.
• The Hiring Committee’s Decision: The final decision rests with the hiring committee, which considers various factors beyond your control, such as budget constraints, team dynamics, and organizational priorities.

Embrace the Process, Learn from Every Experience:

Remember that every interview, regardless of the outcome, is a valuable learning opportunity. Analyze your performance, identify areas for improvement, and seek feedback from others. Don’t be discouraged by rejections – view them as stepping stones toward your ultimate goal.

Failure is a part of the process. Even the most experienced engineers face rejection at some point in their careers. What matters is how you respond to setbacks. Use each experience to refine your skills, expand your knowledge, and strengthen your resolve.

Keep practicing, keep learning, and keep pushing yourself. The ri

README 内容过长，已截取前 64 KB。完整内容请前往 GitHub 仓库查看。