1. Design Pattern
1.1. Delegation Pattern
2. Interview Experience
2.1. Loading...
3. Papers
3.1. Amazon - Dynamo paper
3.2. Google - Map-reduce paper
3.3. Google - GFS paper
3.4. Facebook - TAO paper
4. API Design
4.1. RPC
4.1.1. example: Shortlister.nominateSkill
4.1.2. Requirement
4.1.2.1. low latency
4.1.2.2. in the same organization
4.1.2.3. complex activity/method
4.1.3. Fact
4.1.3.1. could build on HTTP
4.1.3.2. changing/upgrading API is hard.
4.2. REST
4.2.1. example: SOSS
4.2.2. Requirement
4.2.2.1. can easily support extension
4.2.3. Facts
4.2.3.1. more overhead than RPC
4.2.3.2. on HTTP
4.2.3.3. use native HTTP actions: GET/PUT.
4.3. GraphQL
4.3.1. example: Cortex
5. Architecture Design
5.1. Throttling
5.2. Distributed Cache
5.2.1. how do I know which host the k-v item is store?
5.2.2. Does cache item size has a limit?
5.2.3. Does cache host need to communicate with each other?
5.2.4. when do you need to implement a cache?
5.3. Partitioning / Replication
5.4. Criteria
5.4.1. Availability
5.4.2. Scalability
5.4.3. Fault-tolerance
6. Distributed System
6.1. Eventually Consistency
6.2. Strong Consistency
6.2.1. distributed system co-ordinators such as Zookeeper. It facilitates communication & helps maintain a consistent state amongst the several running cache nodes.
7. Other Materials
7.1. donnemartin/system-design-primer
8. OOD
8.1. Evaluation Aspects
8.1.1. 1. Comfortable with interfaces vs. abstract classes
8.1.1.1. abstract: has common properties & actions
8.1.1.2. interface: can-do common actions
8.1.2. 2. Prefer composition over inheritance
8.1.2.1. why is it good?
8.1.2.1.1. It can leverage dependency injection, therefore good for testing.
8.1.2.1.2. Decouple components & has good isolation and therefore is maintainable and extendable
8.1.3. 3. Familiar with design patterns
8.1.3.1. factory
8.1.3.2. builder
8.1.3.3. singleton
8.1.4. 4. Familiar with general principles like Inversion of Control - DI/IoC.
8.1.5. 5. Think about error handling.
8.2. how to approach to a good design?
8.2.1. Step1: ASK for a lot of clarifications
8.2.1.1. only ask relevant questions to [the problem]
8.2.2. Step 2: Ask for E2E use case
8.2.2.1. Draw a simple workflow diagram
8.2.3. Step3: Entity, Properties, Methods
8.2.3.1. list the State/Properties required
8.2.3.1.1. are they shared across multiple entities?
8.2.3.1.2. has
8.2.3.2. List all the Actions required in the scenario
8.2.3.2.1. are they shared across multiple entities?
8.2.3.2.2. can
8.2.3.3. what design pattern you can use?
8.2.4. Step 4: Exception Handling: where can an error occur? What are the most vulnerable areas?
8.2.4.1. integration points
8.2.4.2. functional points
8.3. Example
8.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.
9. Behavior Questions
9.1. Tools for behaving professionally
9.1.1. Identify Problems and can describe it concisely.
9.1.2. Identify Dependencies
9.1.3. Sort Priority
9.1.4. Be transparent
10. Web
10.1. C/S Connections
10.1.1. HTTP
10.1.1.1. unidirectional
10.1.1.2. stateless
10.1.1.3. Keep-alive
10.1.1.3.1. performance
10.1.1.3.2. Cannot do Server -> Client comparing to WebSocket
10.1.1.4. Android Tool: Retrofit
10.1.1.5. HTTPS
10.1.1.5.1. HTTPS uses an encryption protocol to encrypt communications. The protocol is called Transport Layer Security (TLS), although formerly it was known as Secure Sockets Layer (SSL).
10.1.2. Websocket
10.1.2.1. problem
10.1.2.1.1. RealTime App like trading App
10.1.2.1.2. Gamming
10.1.2.1.3. Chatting App
10.1.2.2. bidirectional
10.1.2.3. ws://
10.1.2.4. stateful
10.1.2.5. Android Tool Scarlet
10.1.3. Communications Between Client and Server
10.1.3.1. Long Polling
10.1.3.2. SSE
10.1.3.3. Ajex Polling
10.2. Response Code
10.2.1. 1xx
10.2.1.1. informational
10.2.1.1.1. 100: everything so far is OK and that the client should continue the request
10.2.2. 2xx
10.2.2.1. success
10.2.3. 3xx
10.2.3.1. redirection
10.2.4. 4xx
10.2.4.1. client error
10.2.5. 5xx
10.2.5.1. service error
10.3. What happens when you try to login to amazon website and add things to the shopping cart?
10.3.1. 0. The browser checks the cache for a DNS record to find the corresponding IP address
10.3.2. 1. if cache missed, ask DNS to Lookup IP address for the entered domain
10.3.3. 2. Client receives the IP address of the destination server.
10.3.3.1. Highly chance you will hit the CDN first
10.3.3.1.1. What is CDN
10.3.4. 3. Since it is under the Https protocol, the Client and Server will complete a TLS handshake.
10.3.4.1. TCP Handshake
10.3.4.2. Server reply the CA (public key)
10.3.4.3. Client verify the CA
10.3.5. 4. Service response 2xx, 3xx, 4xx, 5xx
10.3.5.1. if the user has not yet login, the 3xx will redirect the user to the login/authN page
10.3.6. 5. User Authentication/Authorization (AuthN/AuthZ)
10.3.6.1. cookie
10.3.6.1.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.
10.3.6.1.2. Cookies are a means of "ongoing authentication."
10.3.6.2. Case#1: User type in password to conduct Auth directly with original service
10.3.6.3. Case#2 Delegation AuthN/AuthZ
10.3.6.3.1. What is delegation Auth? You can think of this like hotel key cards, but for apps. If you have a hotel key card, you can get access to your room. How do you get a hotel key card? You have to do an authentication process at the front desk to get it. After authenticating and obtaining the key card, you can access resources across the hotel.
10.3.6.3.2. Authentication (AuthN)
10.3.6.3.3. Authorization (AuthZ)
10.3.7. 6. Add goods to your shopping cart
10.3.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.
10.3.7.2. OOD: Design an Amazon Shopping Cart System (Account, Cart, Item, Product)
11. Transaction
11.1. What?
11.1.1. A transaction is an atomic unit of processing, and it either has to be performed in its entirety or not at all.
11.2. Transactional Locking
11.2.1. Optimistic Concurrency Control (OCC)
11.2.1.1. A strategy where you read a record, take note of a version number (or Timestamp) and check that the version hasn't changed before you write the record back.
11.2.1.2. Asynchronous Approach: Saga
11.2.1.2.1. Disadvantage
11.2.1.3. When to use?
11.2.1.3.1. Distributed Database; With priority of performance is also important.
11.2.2. Pessimistic Lock
11.2.2.1. when you lock the record for your exclusive use until you have finished with it. It has much better integrity than optimistic locking but requires you to be careful with your application design to avoid Deadlocks.
11.2.2.1.1. what is deadlocks?
11.2.2.2. Synchronous (blocking) Approach: 2pc (two-phase commit)
11.2.2.2.1. Disadvantage
11.2.2.3. When to use? Accuracy > Performance
11.2.2.3.1. e.g. design an ATM
11.2.3. Patterns for distributed transactions within a microservices architecture
11.3. Scenario
11.3.1. Database running on a single machine
11.3.1.1. E.g. design an ATM
11.3.2. Distributed database
11.3.2.1. Best practice: apply optimistic lock with version# or timestamp
11.4. How? ACID
11.4.1. Atomicity
11.4.1.1. Revert if there is partial failure
11.4.2. Isolation
11.4.2.1. Transactions should not interfere each other
12. Encoding and Evolution
12.1. What is encoding /serialization/marshelling
12.1.1. in-memory representation (e.g. POJO) => a byte sequence
12.1.1.1. What is byte sequence?
12.1.1.1.1. Binary String
12.1.1.1.2. Character String
12.2. Format
12.2.1. 1. Language-Specific Formats
12.2.2. 2. JSON, XML
12.2.2.1. Pros
12.2.2.1.1. human readable
12.2.2.2. Cons
12.2.2.2.1. don't support Binary String.
12.2.3. 3. Binary Schema-Driven Formats
12.2.3.1. Thrift
12.2.3.2. Protocol Buffers
12.2.3.3. Avro
12.3. Data Flow
12.3.1. When?
12.3.1.1. You want to send data to another process with which you don't share memory
12.3.2. How?
12.3.2.1. 1. Database
12.3.2.2. 2. RPC and REST API
12.3.2.3. 3. Message (Async)
13. Design for failure
13.1. Case Study
13.1.1. Batch Job Processing
13.2. Failure Handling
13.2.1. Timeout
13.2.2. Dependency Failure
13.3. Principle
13.3.1. Fail fast