[25] Systems Design - Chapter 4

Question 1

Why Network conditions are unpredictable and why mobile systems should be design for imperfection?

Answer 1

Mobile apps operate in dynamic environments: elevators, subways, rural areas, and congested cities.

signal drops should be as seamless as possible.

Question 2

What are the two tipes of networks in mobile systems?

Answer 2

Cellular Networks

Include 3G, 4G/LTE, and 5G.

Shared and variable: bandwidth fluctuates with coverage, congestion, and signal strength.

Users share capacity; performance degrades in dense or obstructed environments.

Wi-Fi in Mobile Context

Typically faster than cellular but unreliable when users move.

Frequent transitions (e.g. Walking out of a cafe) cause short outages or weak connections.

Devices may prefer Wi-Fi even when signal quality is poor, resulting in degraded performance.

Question 3

Difference between cellular and WiFi?

Answer 3

Question 4

Key constraints of networks in mobile devices?

Answer 4

• Variable Bandwidth and Latency: Throughput changes with movement and congestion.
• Frequent Connection Drops: Network hand-offs (Wi-Fi ↔ cellular, tower changes) cause invisible failures or retries.
• Data Sensitivity: Many users have limited data plans; excess usage leads to poor performance or churn.
• Battery Costs: Every transmission wakes the radio and CPU, draining power.
• Environmental Unpredictability: Elevators, tunnels, and crowds interfere with signals.

Question 5

Because of network constraints, mobile communications should be…. ?

Answer 5

1. Resilient
2. Adaptive

Question 6

Core principles of Recilient and Adaptive network connection in mobile systems?

Answer 6

• Minimize Round-Trips Achieve more per request to reduce latency and failure risk.
• Conserve Bandwidth Send only essential data; avoid redundancy.
• Expect Failure Support retries, resumable flows, and eventual consistency.
• Work Asynchronously Queue operations and transmit opportunistically.
• Prioritize Critical Traffic Send user-visible actions before background syncs.
• Bundle Intentionally Combine related operations to reduce radio wakeups and overhead.
• Adapt to Conditions Adjust sync frequency or payload size dynamically.

Question 7

List concrete techniques and architectures to solve connectivity issues:

Answer 7

• Client–Server Protocols: Evaluate REST, GraphQL, and other APIs for retry support, connection reuse, and efficiency.
• Expect Failure Support retries, resumable flows, and eventual consistency.Work AsynchronouslyQueue operations and transmit opportunistically.
• Data Formats: Weigh trade-offs between readability and size (e.g., JSON vs Protobuf).
• Compare shapes (REST vs GraphQL) for payload size, caching, and reliability.
• Adapt to Conditions Adjust sync frequency or payload size dynamically.

Question 8

Problem:
A user completes a multi-step loan form in a banking app. During submission, the device switches networks and loses connectivity.

Answer 8

• Save progress locally (e.g., Core Data or on-device cache).
• Queue submission for retry when connection resumes.
• Use unique transaction IDs to prevent duplicate uploads.
• Confirm completion asynchronously once the server acknowledges.

Question 9

What protocols are use to comunicate mobile clients with services and data?

Answer 9

Communication occurs via APIs, typically over TCP/IP and secured with TLS (HTTPS).

Question 10

Describe the basic communication flow in mobile apps with servers.

Answer 10

1. DNS Resolution – Converts domain names into IP addresses.
2. TCP Connection – Establishes a connection between client and server.
3. TLS Handshake – Encrypts data for secure communication (HTTPS).
4. HTTP Request/Response Cycle – Transmits structured requests and receives responses.

Note: Mobile platforms (e.g., iOS URLSession, Android OkHttp) abstract this process, allowing developers to make simple API calls without handling low-level networking logic.

Question 11

What is HTTP?

Answer 11

Hypertext Transfer Protocol

HTTP is a stateless, application-layer protocol that underpins most mobile communication. It operates through a request-response model.

Clients send requests using commands like GET, POST, or DELETE.

Servers process the request and return structured data (e.g., JSON).

Question 12

List all HTTP methods

Answer 12

• GET Retrieve data (e.g., fetch user profile) 200 OK, 304 Not Modified
• POST Create new resource (e.g., send message) 201 Created, 400 Bad Request
• PUT Replace entire resource 200 OK, 204 No Content
• PATCH Update part of a resource 200 OK, 204 No Content
• DELETE Remove resource
  200 OK, 204 No Content, 404 Not Found

Key point: Method choice defines how data is transmitted and whether caching or retries are possible.

Question 13

Parts of the structure of a HTTP request

Answer 13

• Method & Target: e.g., GET /users/123 HTTP/1.1
• Headers: Include metadata like authentication tokens, content type, and caching hints.
• Body: Contains payload data (for POST or PUT).

Question 14

Parts of the structure of a HTTP response

Answer 14

Status Line: Includes HTTP version and status code (e.g., HTTP/1.1 200 OK).

Headers: Describe returned content type, length, and caching info.

Body: Carries the requested data (e.g., JSON response).

Security Note: HTTP transmits data in plain text. HTTPS (TLS/SSL) encrypts all parts of the message, protecting data integrity and privacy.

Question 15

What is Remote Procedure Call architecture (RPC)?

Answer 15

RPC allows clients to invoke functions on a remote server where resources are distributed among different services running on remote machines as if they were local calls—ideal for service-to-service or tightly coupled system communication.

Question 16

The table below elaborates on the individual components of a Remote Procedure Call

Answer 16

Question 17

How does RPC works?

Answer 17

RPC follows a request-response model. The client initiates a call, and data is packed and forwarded to the RPC runtime. A network connection is established to transmit the request to the remote server. The server processes the request, and sends back the response through the same process.

Question 18

Why websockts are better thatn RPC?

Answer 18

. WebSockets provide a more suitable alternative for real-time, continuous, and bidirectional communication, essential in features like messaging, live updates, and gaming.

Question 19

How do webSockets work?

Answer 19

WebSocket enables full-duplex, bidirectional communication over a single persistent TCP connection—ideal for real-time apps (e.g., messaging, gaming, live updates).

Question 20

Describe the different use cases of HTTP, RPC and WebSockets

Answer 20

HTTP: Universal, simple, and ideal for standard request-response APIs.

RPC (gRPC): Efficient and structured, best for backend or microservice interactions.

WebSocket: Real-time and continuous communication for user-facing features.

Question 21

Describe the communication flow of webSockets

Answer 21

1. Starts with an HTTP handshake.
2. Sends Upgrade header to switch to the WebSocket protocol.
3. Server replies with 101 Switching Protocols, confirming upgrade.
4. Connection becomes persistent, enabling both client and server to push messages anytime.

Question 22

What architectural styles dominate the communication between mobile apps and backend services?

Answer 22

REST, GraphQL, and gRPC

Question 23

Describe the architectural style properties

Performance -Scalability -ease of development -portability -maintenance

Answer 23

Performance Must handle high request volume without bottlenecks.
Scalability Should easily expand in features or server capacity.
Ease of Development Simplicity and familiarity accelerate development.
Portability Adaptable across environments (mobile, web, desktop).
Maintenance Support Backed by tools, community, and documentation.

Question 24

What is REST?
Representational State Transfer

Answer 24

A widely adopted architectural style that defines constraints for scalable, reliable, and efficient client-server interactions—particularly suitable for mobile apps facing network variability and limited resources.

Question 25

Drawbacks of REST

Answer 25

**Multiple Requests Problem**: Mobile apps often require data from multiple endpoints, resulting in several requests. **Over-Fetching / Under-Fetching**: Fixed endpoints may deliver too much or too little data, wasting bandwidth or requiring additional calls.

Question 26

How GraphQL works?

Answer 26

**Client** sends a query specifying desired fields. **Server** executes resolve functions that gather data from databases or other services. **Response** mirrors the query’s structure for clarity and efficiency.a

Question 27

GraphQL Components

Answer 27

**Schema** Defines data types and relationships; acts as contract between client and server. **Resolve Functions **Map schema fields to data sources or logic for retrieving information. **Client **Executes queries, manages caching, and sends mutations (data modifications).

Question 28

What is gRPC?

Answer 28

An open-source framework by Google (2016) enabling high-performance, real-time communication using HTTP/2 and Protocol Buffers (protobuf) for compact binary serialization.

Question 29

Use cases of gRPC?

Answer 29

Mobile apps needing low latency, real-time updates, or intensive service-to-service communication (e.g., messaging, collaborative apps, trading).

Question 30

How gRPC Works?

Answer 30

1. Client calls a remote procedure through autogenerated stubs. 2. Request serialized into binary format (protobuf). 3. Server processes and returns response or stream via HTTP/2. 4. Bidirectional channels persist, reducing overhead and improving latency. Industry Adoption: Used by Google, Netflix, Cisco, and others for scalable, high-throughput systems.

Question 31

Comparison: REST vs GraphQL vs gRPC

Answer 31

Question 32

What happens if the client expects JSON and the server sends XML?

Answer 32

We need a conversion layer. leading to: * higher CPU usage and battery drain. * Possible data corruption or mismatch after updates.

Question 33

Why XML is not ideal for Mobile?

Answer 33

not ideal for mobile due to large payloads and high latency.

Question 34

Characteristics of XML

Answer 34

Uses custom tags to define data elements. Highly flexible, but verbose.

Question 35

Characteristics of JSON?

Answer 35

Represents data as key-value pairs with support for objects and arrays. Human-readable and language-agnostic. Easier to parse and smaller in size than XML.

Question 36

Characteristics of Binary data Formats?

Answer 36

Binary formats encode data in machine-readable, compact representations—ideal for performance-sensitive mobile applications.

Question 37

Advantages of binary formats?

Answer 37

Smaller payloads → reduced bandwidth and latency. Faster parsing → improved responsiveness and lower CPU usage. Consistent schema → reliable versioning. Cross-platform interoperability.

Question 38

Trade offs of binary formats?

Answer 38

Trade-offs: Not human-readable; debugging requires tools.

Question 39

Common Binary Formats?

Answer 39

1. Thrift and Protobuf 2. Apache Avro 3. FlatBuffers

Question 40

What format to consider between readable and not readable?

Answer 40

JSON → CRUD-based APIs, simple apps, public APIs. (X app) Protobuf / FlatBuffers → Real-time messaging, gaming, live streams. (Whatsapp) Avro → Large-scale data pipelines with frequent schema evolution. (Netflix)

Question 41

Does JSON supports "Backwards compatibility"?

Answer 41

Both, but with some trade-offs. **JSON** * Schema-less: Clients ignore unknown fields, so new keys added on the server usually don’t break older apps. * Easy hot-fixes: You can add or remove fields dynamically, since the structure is text-based. * Backward-compatible by default — as long as the client code handles optional or missing fields safely. Drawbacks: Because there’s no enforced schema, you can accidentally break things by: * Renaming keys, * Changing data types, * Removing expected fields. * Large codebases often end up implementing ad-hoc “version checks” in code, which can get messy.

Question 42

Does Protobuf / FlatBuffers support Backwards compatibility?

Answer 42

✅ Advantages * Both use explicit versioned schemas (.proto / .fbs) with numeric field tags: * Older clients ignore unknown tags, and new servers preserve old tag meanings — so both directions stay compatible. * You can add new optional fields safely without breaking old clients. * You can remove or rename only if you keep the same numeric tags (you can deprecate them safely). * Strong typing prevents subtle bugs — every change must be intentional and version-tracked. ⚠️ Drawbacks Breaking changes (e.g., changing field type or reusing a tag) require coordinated versioning. Harder to evolve quickly without schema planning and automated code regeneration.

Question 43

Why push notifications is an efficient way to keep communication flowing between apps and their backend services?

Answer 43

The OS to maintain a single background connection for all apps, reducing battery usage and enabling message delivery even when apps are inactive. * Battery-efficient and reliable delivery. * Works when apps are in the background or idle.

Question 44

What are the disadvantages of Push Notifications?

Answer 44

No strict real-time guarantee (may be delayed). Limited payload size; larger data requires in-app fetch. Restricted background execution (especially on iOS). Dependency on OS services (APNs/FCM reliability).

Question 45

How does the infrastructure of Push Notifications work?

Answer 45

Question 46

List the 5 different techniques for real time communication

Answer 46

1. **Polling**: App periodically requests updates from the server. 2. **Long Polling**: Server holds request until new data arrives. 3. **Server-Sent Events (SSE)**: Server streams updates to client over HTTP. 4. **WebSockets**: Persistent full-duplex (two-way) connection. 5. **MQTT (Message Queuing Telemetry Transport):** Lightweight publish-subscribe protocol optimized for mobile and IoT.

Question 47

How can I matain communication with a hybrid approach?

Answer 47

Concept: Combine multiple techniques dynamically for the best experience. Common Hybrid Model: Foreground: Maintain a WebSocket connection for low latency. Background: Switch to push notifications for updates or to wake the app. Adaptive strategies: * Use push to reconnect sockets. * Fall back to polling when connection drops. * Adjust heartbeat frequency on low battery.

Question 48

Techniques used for: 1. Whatsapp? (for messages) 2. Uber? (for live tracking and arrival events) 3. Instagram? ( updates and live sessions)

Answer 48

**WhatsApp** Persistent socket for messages; push only for notifications. **Uber** WebSockets for live tracking; push for events like ride arrival. **Instagram** Push for most updates; real-time sockets during live sessions.

Question 49

If the app needs connectivity ? 1. Occasional updates 2. Real-time while active 3. Low-power continuous updates 4. Background fallback 5. Simple architecture

Answer 49

1. Push Notifications 2. WebSockets 3. MQTT 4. Silent Push + Reconnect 5. Polling (if acceptable)