Design

Machine Learning Math

Get Started. It's Free
or sign up with your email address
Design by Mind Map: Design

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