From f35852b69d89cdb31f07024d369baf272ea039d6 Mon Sep 17 00:00:00 2001 From: freemanzhang Date: Tue, 20 Dec 2016 13:10:50 -0800 Subject: [PATCH] chunk up classic system design topics --- README.md | 26 ++++++++++++++++++-------- linkedin/TinyURL.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 47 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index c85583c..782af51 100755 --- a/README.md +++ b/README.md @@ -106,6 +106,24 @@ * [Read consistency](#workflow-scale-read-consistency) * [Tradeoffs between availability and consistency](#workflow-scale-tradeoff-availability-consistency) * [Tradeoffs between latency and durability](#workflow-scale-tradeoff-latency-durability) +* [File system design](#file-system-design) +* [Database design](#database-design) + - [Read-only Key-value](#database-design-key-value) + - [Read write key-value](#database-design-read-write-key-value) +* [MapReduce](#map-reduce) + - [Anagram](#map-reduce-anagram) + - [TopK](#map-reduce-topk) +* [Web system](#web-system) + - [Typeahead](#web-system-type-ahead) + - [TinyURL](#web-system-tiny-url) +* [Message](#newsfeed) + - [Twitter](#newsfeed-twitter) + - [Messenger](#newsfeed-messenger) +* [Location based service](#location-based-service) +* [User system](#user-system) +* [Multithreading](#multithreading) + - [Thread-safe producer and consumer](#multithreading-thread-safe-producer-and-consumer) + - [Delayed scheduler](#multithreading-delayed-scheduler) * [Technologies](#technologies) - [Minification](#technologies-minification) - [Cassandra](#cassandra) @@ -629,11 +647,6 @@ # Typical system design workflow ## Scenarios ### Features -#### Common features -* User system - - Register/Login - - User profile display/Edit -* Search ### Design goals @@ -650,9 +663,6 @@ ## Service ## Storage -### MySQL index - - ## Scale diff --git a/linkedin/TinyURL.md b/linkedin/TinyURL.md index 6e52737..0806ae5 100644 --- a/linkedin/TinyURL.md +++ b/linkedin/TinyURL.md @@ -1,5 +1,9 @@ # TinyURL * [Description](#description) +* [Scenarios](#scenario) + - [Features](#scenario-features) + - [Design goals](#scenario-design-goals) + - [Estimation](#scenario-estimation) * [Service](#service) - [Insert](#service-insert) + [Encode](#service-insert-encode) @@ -19,6 +23,29 @@ Design tiny URL 问了很多细节，最后居然问到了怎么配置memcache, 其实都需要index, 然后根据需要load进cache，但是这些普通数据库都已经实现了，不需要我们操心。 当然你可以把index都load到memcache/redis加快点访问速度，不过这里都是没有必要的。 +## Scenario +### Features +* Shortening: Take a url and return a much shorter url. + - Ex: http://www.interviewbit.com/courses/programming/topics/time-complexity/ => http://goo.gl/GUKA8w/ + - Gotcha: What if two people try to shorten the same URL? +* Redirection: Take a short url and redirect to the original url. + - Ex: http://goo.gl/GUKA8w => http://www.interviewbit.com/courses/programming/topics/time-complexity/ +* Custom url: Allow the users to pick custom shortened url. + - Ex: http://www.interviewbit.com/courses/programming/topics/time-complexity/ => http://goo.gl/ib-time +* Analytics: Usage statistics for site owner. + - Ex: How many people clicked the shortened url in the last day? + +### Design goals +* Latency + - Our system is similar to DNS resolution, higher latency on URL shortener is as good as a failure to resolve. +* Consistency vs Availability + - Both are extremenly important. However, CAP theorem dictates that we choose one. Do we want a system that always answers correctly but is not available sometimes? Or else, do we want a system which is always available but can sometime say that a URL does not exists even if it does? This tradeoff is a product decision around what we are trying to optimize. Let's say, we go with consistency here. +* URL as short as possible + - URL shortener by definition needs to be as short as possible. Shorter the shortened URL, better it compares to competition. + +### Estimation +* + ## Service ```java class TinyURL @@ -153,3 +180,5 @@ class TinyURL ### NoSQL +## Scale +