System Design and Scaleability Questions

Kom i gang. Det er Gratis
eller tilmeld med din email adresse
System Design and Scaleability Questions af Mind Map: System Design and Scaleability Questions

1. Handling the Questions

1.1. Communicate

1.2. Go broad first

1.2.1. consider easy to use clients owners flexibility scalability and efficiency

1.3. Use the whiteboard

1.3.1. help interviewer follow your proposed design

1.4. Acknowledge interviewer concerns

1.4.1. validate them make changes accordingly

1.5. Be careful about assumptions

1.5.1. State them explicitly

1.6. Estimate when necessary

1.7. Drive

1.7.1. ask questions be open about tradeoffs go deeper

2. Design

2.1. Systems (SMraDIR)

2.1.1. Scope the Problem what exactly you need to implement list major features

2.1.2. Make Reasonable Assumptions Evaluate "product sense"

2.1.3. Draw the Major Components What the system might look like Walk through from end-to-end to provide a flow Pretend to ignore major scaleability challenges at the moment

2.1.4. Identify the Key Issues What will be the bottlenecks or major challenges?

2.1.5. Redesign for the Key Issues Be open about limitations in your design

2.2. Algorithms (AMaGS)

2.2.1. Ask Questions

2.2.2. Make Believe pretend that data can fit on one machine provide the general outline for your solution

2.2.3. Get Real How much data can fit on one machine? What problems will occur when you split up the data?

2.2.4. Solve problems a solution can remove or mitigate an issue Mind iterative approach Solve problems as they emerge

3. Key Concepts

3.1. Horizontal vs. Vertical Scaling

3.1.1. Vertical increasing the resources of a specific node

3.1.2. Horizontal increasing number of nodes

3.2. Load Balancer

3.2.1. software application DNS based

3.2.2. hardware routers

3.3. Database Denormalization and NoSQL

3.3.1. to avoid joins

3.4. Database Partitioning (Sharding)

3.4.1. Vertical Partitioning by feature if one db gets very large you might need to repartition db

3.4.2. Key-Based (or Hash-Based) Partitioning adding new servers means reallocating all data

3.4.3. Directory-Based Partitioning lookup table can be a single point of failure consider ranges and duplicating the table accessing the table impacts performance

3.5. Caching

3.5.1. in-memory between your app layer and your data store

3.6. Asynchronous Processing & Queues

3.6.1. pre-process notifying when the process is done

3.7. Networking Metrics

3.7.1. Bandwidth (bit/s, Gbits/s) Max amount of data that can be transferred in a unit of time Best conditions

3.7.2. Throughput Actual amount of data that is transferred in time In real

3.7.3. Latency How long it takes data to go from one end to the other Delay between the sender and receiver

3.8. MapReduce

3.8.1. Map Takes in some data and emits a <key,value> pair

3.8.2. Reduce Takes a key and a set of associated values and "reduces" them, emitting a new key and value The result can be reduced again

4. Considerations (FARS-RW)

4.1. Failures

4.1.1. Plan for many or all of them

4.2. Availability

4.2.1. Uptime / Total time operational availability-> function of the percentage of time the system is operational

4.3. Reliability

4.3.1. Mean Time Between Failure (MTBF) = total time in service / number of failures

4.3.2. Failure Rate = number of failures / total time in service

4.3.3. a reliable machine has high availability but an available machine may or may not be very reliable

4.4. Security

4.5. Read-heavy vs. Write-heavy

4.5.1. caching vs queuing up the writes

5. Demonstrate you can analyse the problems