I. Introduction and Scope

This video is the second in the System Design Building Block series, intended to help developers choose the appropriate data storage location on the client side.

A. What is Storage?

• A place where data is stored.

• The simplest storage is JavaScript memory (storing variable values).

• Storage is needed in almost any application that needs to store data, except simple static HTML sites.

B. Problem Solved

• It is often difficult for developers to choose the right place for storing data.

• Some storages (like Local Storage) are overused, while others (Session Storage, IndexDB) are relatively less popular.

C. Storages Covered

• URL.

• Cookies.

• Session Storage.

• Local Storage.

• Cache API.

• IndexDB.

• Remote Databases.

D. Storages Excluded

• File System API: Poor browser support.

• WebSQL: Deprecated and replaced by IndexDB.

E. Key Term: Origin

• An Origin is the combination of protocol, host name, and port.

  • Protocol examples: HTTP or HTTPS.

  • Port is usually hidden (using default port).

• Example: example.com and example.com/app/index.html have the same Origin.

II. Client-Side Storages

1. URL Search Parameters (Query String)

Although not obvious, the URL query string can be used as storage.

• Persistence/Lifetime: Survives a page refresh, but is lost when the page is closed. Not a safe place to store data.

• Key Advantage: Easy to share with other users and can be saved in browser bookmarks.

• Security/Capacity: Data is visible (not secure). Small capacity (e.g., 2,000 symbols limit in Microsoft Edge).

• Data Suitability: Suitable mainly for short and primitive data (string, number, boolean).

• Use Cases:

  • Current Page State (configured view on a dashboard or map).

  • Navigation State (page number, filter, search query in a table component or online shop).

2. Cookies

• Unique Features: Can be set by the server and are automatically sent to the server with every HTTP request.

• Security: Widely supported and easy to use. Can provide better protection against XSS attacks using the HTTP only parameter.

• Drawbacks: Limited storage capacity (~4 kilobytes per origin). Increases HTTP overhead because they are sent with every request.

• Storage Role: Not considered a complete storage solution for data.

• Use Cases:

  • Session Management (ideal as JavaScript management is not required for sending session info).

  • Personalization (server reads cookies to display a personalized page).

  • Tracking User Behavior (user ID set by an advertisement provider for personalized ads).

3. Local Storage

• Persistence: Persistent storage (data is not deleted after a certain time, provided quotas are respected). Not fully reliable for critical data.

• Ease of Use: Simple and easy to use.

• Drawbacks:

  • API is slow and synchronous; operations occupy the main thread. Not available inside Web or Service Workers.

  • Limited capacity (typically 5 MB per origin). Supports only strings; encoding/decoding is required.

• Scalability: Not scalable; effective only for small amounts of data.

• Use Cases:

  • Persistent client storage (user settings, selected theme, language).

  • Offline usage (store results temporarily to send later).

  • Saving drafts (simple user input).

4. Session Storage

• Persistence/Lifetime: Retains data during tab refreshes. Cleared when the tab is closed.

• Tab Behavior: Does not transfer data between tabs. A duplicated tab shares the session store with the original tab.

• Capacity: 5–15 MB. Operates under a separate quota system.

• Key Advantage: Automatic clearing at the end of the session.

• Drawbacks: Inherits drawbacks from Local Storage (string-only, synchronous API).

• Use Cases:

  • Caching server data for the session.

  • Data sharing across screens (multi-step processes like Wizards).

  • Storing global configuration (alternative to global variables).

5. Cache API

• Purpose: Specifically for storing server responses; not for general storage like Local/Session Storage.

• Accessibility: Accessible in Web and Service Workers.

• Mechanism: Service Worker intercepts requests; if not in cache, it requests from the server and caches the response. Subsequent requests are served from cache.

• Use Cases:

  • Enables offline mode by caching assets (HTML, CSS, static files).

  • Reduces network requests and speeds up page loads.

  • Used in apps like Slack for efficient loading and offline functionality.

Cache API vs. Browser Cache

6. IndexDB (Indexed Database)

• Power/Capacity: Very powerful; supports indexing, transactions, versioning, and large capacity.

• API: Asynchronous and fast. Available in Web and Service Workers.

• Complexity: Steep learning curve; wrappers like IDB can help.

• Major Problems:

  • Safari ITP deletes inactive data after 7 days.

  • Private mode often blocks storage.

  • Browser quotas are inconsistent.

• Use Cases:

  • Storing large amounts of structured data.

  • Storing binary files (media for offline use).

  • Offline-first applications.

III. Quotas and Eviction Policy

A. Quota Systems

Quota is the disk space the browser allocates for data storage.

B. Eviction Policy

Even persistent storages can delete data.

IV. Remote Databases

• Advantages:

  • Reliable and secure.

  • Allows data sharing across devices.

• Disadvantages:

  • Complexity and high costs.

  • Slower interface (network required).

  • Impossible offline without additional mechanisms.

• Use Cases:

  • Sensitive data (credentials).

  • Data that needs sharing between devices.

  • Important and critical data.

V. Storage vs. Storage Manager

• Storage: Physical disk space with API, varying capacities and lifetimes.

• Storage Manager: Works on top of storage. Provides an interface (CRUD, subscriptions) but no physical space.

• Example: Redux provides temporary and permanent storage options.

VI. Decision-Making Example (Facebook)

• URL, Cookies, and Cache API are often eliminated first (specific use cases).

• Choice depends on data lifetime and importance.

A. Case 1: Search Parameters

• Filters and sorting configuration are short-lived and may need sharing/bookmarks.

• Choice: URL Search Parameters

B. Case 2: Post Drafts

• Require long-term storage, complex structures, and multi-device access.

Strategy:

1. Primary: Remote Database – most reliable, allows sharing.

2. Offline Mode: IndexDB – faster, no backend needed, but less reliable.

Synchronization Strategy:

1. User Online: Save drafts to Remote Database.

2. User Offline: Save drafts to IndexDB.

3. User Back Online: Synchronize IndexDB with Remot Database.