Complete System Design Interview Preparation

Design a url shortener service that creates short aliases redirecting to long urls, like tiny url or bit.ly, to save space and reduce mistyped links while enabling tracking.

Clarify the goals and requirements for a URL shortening system, covering functional, non-functional, and extended needs like unique short links, redirects, expiration, high availability, and REST API analytics.

Estimate capacity for a read-heavy service with a 100 to 1 read-write ratio, yielding 200 URLs per second and 20,000 redirections, with 30 billion objects and 15 TB storage.

Define the main system apis for a url shortening service, detailing create and delete endpoints with an api developer key, original url, optional alias, expiry, and abuse prevention quotas.

Architect a scalable NoSQL database design for a URL shortener by defining a two-table schema for mappings and users, focusing on read-heavy access and billions of small records.

Explore methods to generate a short and unique URL key, comparing md5-based hashing with base64 encoding and collision-avoidance strategies like sequence numbers or user IDs, plus scalability considerations.

Explore a standalone key generation service that pre-generates random six-letter keys stored in a key database, addressing concurrency via unused and used keys, memory caching, and locks.

Explore scale strategies by partitioning a URL database with range-based and hash-based schemes, addressing unbalanced partitions and introducing consistent hashing.

Cache hot URLs with hashes using memcache to speed up services and serve 20% daily traffic. Use LRU eviction and cache replicas to distribute load and synchronize updates after misses.

Explore the load balancing layer across the client, app servers, database, and caching servers, starting with round robin and evolving to intelligent load-aware routing.

Explore purging and database cleanup strategies, including expiration handling, lazy cleanup, and on-access deletion. Implement periodic lightweight cleanup, default expiration, and key reuse to balance storage costs and performance.

Capture telemetry by recording internal usage counts, locations, and metrics, and implement permissions for private URLs using a Cassandra NoSQL table keyed by the URL hash with user IDs.

This lecture outlines the final system design for a URL shortener, highlighting the client, load balancer, application servers, URL and key databases, key generation service, caching, and clean-up service.

Examine pastebin services that store plain text or images, generate unique non-guessable URLs with expiration times and optional custom aliases, while addressing reliability, availability, latency, analytics, and REST API access.

Explore design considerations for a pastebin-like service, including limits on paste size and custom URLs, and estimate capacity with a 5:1 read/write ratio and 1 million new pages daily.

Learn system apis for a pastebin service using soap or rest, covering paste creation, retrieval, and deletion with api developer key, data, optional url, and expiration.

Design a scalable database for billions of records with separate metadata and content stores, enabling a read-heavy 5:1 ratio and independent scaling of the application and storage layers.

Describe component design of the application layer, including write and read workflows, six-letter key generation, duplicate handling, and a two-tier data store with metadata and object storage.

Explore other bottleneck concerns in this app, including purging, database cleanup, data partitioning and replication, caching and load balancing, security and permissions, using the approach from the URL shortener.

Present Pastebin system design diagram, detailing client and application servers with load balancing, caching layers, object storage, metadata storage, and a key generation service with a standby key database replica.

Design a photo sharing service like Instagram, enabling upload, view, search by photo titles, and a newsfeed of top posts with 200 ms latency, high availability, and reliability.

Build a high load photo service with reliable storage and low latency, estimating capacity and supporting upload and view or search flows using object storage for images and metadata database.

Explore a proposed Instagram‑style database schema, detailing relational versus NoSQL designs, partitioning considerations, and data size estimation for users, photos, and follows.

Split reads and writes into separate services to prevent bottlenecks and enable independent scaling of image upload and download operations, with replicas and backups ensuring high availability.

Master data sharding and partitioning for scalable storage, exploring user-id and photo-id shard schemes, autoincrement id generators, hot-user challenges, latency and availability concerns, and config-driven partition migration for future growth.

Rank and generate the newsfeed by selecting 100 photos from followed users using a ranking algorithm, with sharded epoch-time photo IDs and a hybrid pool‑and‑push approach to reduce latency.

Cache and CDNs enable global photo delivery by caching hot metadata with memcache, using an LRU eviction policy, and applying the 8020 rule to reduce reads.

Design a scalable Instagram-like system using a web or mobile client, load balancers, read and upload image services, and a newsfeed service with cache, storage, and replicated components.