1. [Use Case] What happens when you try to login to amazon website and add things to the shopping cart?
1.1. 0. The browser checks the cache for a DNS record to find the corresponding IP address
1.2. 1. if cache missed, ask DNS to Lookup IP address for the entered domain
1.3. 2. Client receives the IP address of the destination server.
1.3.1. Highly chance you will hit the CDN first
1.3.1.1. What is CDN
1.4. 3. Since it is under the Https protocol, the Client and Server will complete a TLS handshake.
1.4.1. TCP Handshake
1.4.2. Server reply the CA (public key)
1.4.3. Client verify the CA
1.5. 4. Service response 2xx, 3xx, 4xx, 5xx
1.5.1. if the user has not yet login, the 3xx will redirect the user to the login/authN page
1.6. 5. User Authentication/Authorization (AuthN/AuthZ)
1.6.1. See AuthN in the Security Section
1.7. 6. Add goods to your shopping cart
1.7.1. The items should be still in the shopping cart even after the session/token is expired. Thus, the shopping cart information should be store in database.
1.7.2. OOD: Design an Amazon Shopping Cart System (Account, Cart, Item, Product)
2. Web
2.1. C/S Connections
2.1.1. HTTP
2.1.1.1. Type
2.1.1.1.1. Regular HTTP
2.1.1.1.2. Client to wait for changes in Server side
2.1.1.1.3. HTTP Streaming
2.1.1.2. http(s)://
2.1.1.3. Direction
2.1.1.3.1. Client to initiate request
2.1.2. Websocket
2.1.2.1. Ten times faster than HTTP
2.1.2.2. problem
2.1.2.2.1. RealTime App like Google Map, trading App
2.1.2.2.2. Gamming
2.1.2.2.3. Chatting App
2.1.2.3. What
2.1.2.3.1. The client initially connects to the server. Then the Web Socket server doesn't let go of this connection after acknowledging to the client that the request has been received. Then the Web Socket server and the client can communicate both ways at any moment without delay (ideally without blocking).
2.1.2.4. Direction
2.1.2.4.1. bidirectional
2.1.2.5. ws://
2.1.2.6. stateful
2.1.2.7. Android Tool Scarlet
2.2. Response Code
2.2.1. 1xx
2.2.1.1. informational
2.2.1.1.1. 100: everything so far is OK and that the client should continue the request
2.2.2. 2xx
2.2.2.1. success
2.2.3. 3xx
2.2.3.1. redirection
2.2.4. 4xx
2.2.4.1. client error
2.2.5. 5xx
2.2.5.1. service error
3. Network
3.1. OSI
3.1.1. Data
3.1.1.1. 7. Application Layer
3.1.1.1.1. HTTP
3.1.1.1.2. WebSocket
3.1.1.1.3. FTP
3.1.1.2. 6. Presentation Layer
3.1.1.2.1. Encryption
3.1.1.3. 5. Session Layer
3.1.1.3.1. Session is a Logical C/S Connectivity, stored in Service side
3.1.2. Connection
3.1.2.1. 4. Transport Layer
3.1.2.1.1. TCP, UDP
3.1.3. 3. Network Layer
3.1.3.1. IP v4, IP v6
3.1.4. 2. Data Link Layer
3.1.4.1. Ethernet
3.1.5. 1. Physical Later
3.1.5.1. UPS, Bluetooth, IEE802.11
4. Security
4.1. Encryption
4.1.1. How
4.1.1.1. asymmetric key
4.1.1.1.1. Private Key
4.1.1.1.2. Public Key (Contained in CA)
4.1.2. HTTPS
4.1.2.1. TLS/SSL
4.2. cookie
4.2.1. what's a cookie for? The answer: Session state — i.e. something that the server/application wants to know about you on the next request.
4.2.2. Cookies are a means of "ongoing authentication."
4.2.2.1. Server will create a session ID/Token
4.2.2.2. The session ID is an encrypted token
4.2.2.3. ClientSide
4.2.2.3.1. The client cookies stores the sessionID/Token
4.2.2.4. ServerSide
4.2.2.4.1. Password
4.2.2.4.2. Delegation
4.3. AuthN
4.3.1. How?
4.3.1.1. Access Token
4.3.1.1.1. Type
4.3.1.1.2. How Do Access Tokens Work?
4.3.1.1.3. What if I have multiple load balancers due to my microservices architecture?
4.3.2. Type
4.3.2.1. Case#1: User type in password to conduct Auth directly with original service
4.3.2.2. Case#2 Delegation AuthN
4.3.2.2.1. Authentication (AuthN)
5. System Design Interview
6. OOD
6.1. Evaluation Aspects
6.1.1. 1. Comfortable with interfaces vs. abstract classes
6.1.1.1. abstract: has common properties & actions
6.1.1.2. interface: can-do common actions
6.1.2. 2. Prefer composition over inheritance
6.1.2.1. why is it good?
6.1.2.1.1. It can leverage dependency injection, therefore good for testing.
6.1.2.1.2. Decouple components & has good isolation and therefore is maintainable and extendable
6.1.3. 3. Familiar with design patterns
6.1.3.1. factory
6.1.3.2. builder
6.1.3.3. singleton
6.1.4. 4. Familiar with general principles like Inversion of Control - DI/IoC.
6.1.5. 5. Think about error handling.
6.2. how to approach to a good design?
6.2.1. Step1: ASK for a lot of clarifications
6.2.1.1. only ask relevant questions to [the problem]
6.2.2. Step 2: Ask for E2E use case
6.2.2.1. Draw a simple workflow diagram
6.2.3. Step3: Entity, Properties, Methods
6.2.3.1. list the State/Properties required
6.2.3.1.1. are they shared across multiple entities?
6.2.3.1.2. has
6.2.3.2. List all the Actions required in the scenario
6.2.3.2.1. are they shared across multiple entities?
6.2.3.2.2. can
6.2.3.3. what design pattern you can use?
6.2.4. Step 4: Exception Handling: where can an error occur? What are the most vulnerable areas?
6.2.4.1. integration points
6.2.4.2. functional points
6.3. Example
6.3.1. Design a set of classes for Alexa devices that can report the current battery/power status to the user e.g. 1. echo dot - "Alexa, what is your power state?" => say "Currently plugged into wall power" 2. echo show - "Alexa, what is your power state?" => say "Currently plugged into wall power" and display the power state 100%. 3. portable echo show - "Alexa, what is your power state?" => say "Current battery level is 75%" and display the power state 75%. 4. portable echo case 1: portable echo - "Alexa, what is your power state?" => battery Say "Current battery level is 75% and charging" through the speaker. case 2: portable echo - "Alexa, what is your power state?" => battery Say "Current battery level is 75%" through the speaker.
6.4. Design Pattern
6.4.1. Delegation Pattern
7. API Design
7.1. Communication Style
7.1.1. Async (NonBlocking)
7.1.1.1. Pattern: Messaging
7.1.1.2. Pattern: Callback function
7.1.1.2.1. A callback function is a function passed into another function as an argument
7.1.2. Sync (Blocking)
7.1.2.1. Pattern: Remote Procedure Invocation (RPI)
7.1.2.1.1. Types
7.1.2.2. You can also use RPI in an async manner by using callback function in the client side.
7.2. API Contract
7.2.1. Semantic Versioning
7.2.1.1. {MAJOR}.{MINOR}.{PATCH}
7.2.1.1.1. example: 1.12.2
7.2.1.2. MAJOR is NOT backward-compatible
7.2.1.3. MINOR is backward-compatible new feature
7.2.1.4. PATCH is backward-compatible bug fix
7.3. Reference
7.3.1. Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC
7.3.2. REST vs. RPC: what problems are you trying to solve with your APIs? | Google Cloud Blog
8. Design Best Practise
8.1. The Design Process
8.1.1. "4S"
8.1.1.1. 1. Scenario
8.1.1.1.1. Use Cases
8.1.1.1.2. DAU (Daily Active User)
8.1.1.1.3. Interface
8.1.1.2. 2. Service(s)
8.1.1.2.1. 1. Data Model
8.1.1.2.2. 2. Interface
8.1.1.2.3. 3. Access patterns
8.1.1.2.4. 4. Identify MicroServices
8.1.1.3. 3. Storage
8.1.1.3.1. DB
8.1.1.3.2. File System
8.1.1.3.3. Cache
8.1.1.3.4. Index
8.1.1.4. 4. System Optimization
8.1.1.4.1. 1. Performance
8.1.1.4.2. 2. Scalability
8.1.1.4.3. 3. Fault-tolerance
8.2. Design Question
8.2.1. News Feed
9. Others
9.1. Papers
9.1.1. Amazon - Dynamo paper
9.1.2. Google - Map-reduce paper
9.1.3. Google - GFS paper
9.1.4. Facebook - TAO paper
9.2. Topics to be covered
9.2.1. DDOS
9.2.2. rate limiting
9.2.3. idempotation
9.3. Other Materials
9.3.1. donnemartin/system-design-primer