Book

We are continuing to study an interesting book about Google’s culture and practices:

Chapter 2 covers:

• Working in isolation vs working in a team.
• Amount of time that you and your team spend communicating and in interpersonal conflict. How a small investment in understanding personalities and working styles of yourself and others can go a long way toward improving productivity.
• If you want to work effectively with a team or a large organization, be aware of your preferred working style and that of others.

Here is the book we are studying:

Our IT books club has started reading new book - about Software Engineering at Google - processes, culture, and tools that help Google create and maintain high-quality software. First chapter is about Software Engineering in general:

• What is Software Engineering vs Software Development/Programming?
• Three principles Google consider:
  • Time and Change
  • Scale and Growth
  • Trade-offs and Costs
• How these three principles are applied to Software Engineering and how it is different from Software Development/Programming

Interesting opening chapter of the book:

The previous chapters have described the underlying technologies such as consistent hashing, ID generator, and now using these techniques we can develop a URL shortener that can generate 100 million URLs per day.

Design consists of the following elements:

• API endpoints
• URL redirecting
• URL shortening
• Data model
• Hash functions: Hash + collision resolution vs Base-62 conversion
• Additional topics to consider:
  • Rate limiter
  • Web server scaling
  • Database scaling
  • Analytics
  • Availability, consistency, and reliability

These items are disclosed in a very interesting Chapter 8 of the book:

Generating unique ID seems to be a simple task, but it is not in a high-load distributed systems!

This topic consists of:

• Understanding the requirements and why it is a complicated task
• Possible solutions:
  • Multi-master replication
  • Universally unique identifier (UUID)
  • Ticket server
  • Twitter SNOWFLAKE approach (seems to be the best one!)
• Details:
  • Timestamp
  • Sequence number
• Other issues
  • Clock synchronization
  • Section length tuning
  • High availability

These items are disclosed in a very interesting Chapter 7 of the book:

Key-Value stores are the most basic but widely used data storages.

Design of key-value store consists of understanding the following topics:

• What do we want from key-value store?
• Single server key-value store
• DISTRIBUTED key-value store:
  • CAP theorem
  • Real-world trade-offs for distributed systems
• System components:
  • Data partition
  • Data replication
  • Consistency
  • Inconsistency resolution: Versioning
  • Handling all types of failures: Failure detection, Handling TEMPORARY failures, Handling PERMANENT failures, Handling data center outage
• System architecture diagram
• Write path
• Read path

These items are disclosed in a very interesting Chapter 6 of the book:

Consistent Hashing is a cornerstone technology for distributed systems. Many of software developers don’t realize it, but Consistent Hashing is needed in many places: load balancers, caches, CDNs, id generators, databases, chats / social networks, and many other systems.

This topic consists of:

• Problem with rehashing and why we need hashing to be CONSISTENT
• Hash space and hash ring
• BASIC approach (introduced by Karger et al. at MIT)
• Advanced approach with VIRTUAL NODES

These items are disclosed in a very interesting Chapter 5 of the book:

Every popular software should have a Rate Limiter. It prevents DDOS attack, reduces cost and prevents servers from being overloaded.

There are some tricky questions to be considered during implementation of Rate Limiter:

• Where to put Rate Limiter: client-side, server-side, gateway?
• Algorithms for rate limiting. There are many algorithms with pros and cons: Token bucket, Leaking bucket, Fixed window counter, Sliding window log, Sliding window counter. Your business needs will define the right algorithm.
• How are rate limiting rules created?
• Where are the rules stored?
• How to handle requests that are rate limited?

These questions are disclosed in a very interesting Chapter 4 of the book:

Four standard steps for system design interview. However, I would think about them wider: as about four initial steps to design the software.

• Step 1. Understand the problem and establish design scope
• Step 2. Propose high-level design and get buy-in
• Step 3. Design deep dive
• Step 4. Wrap up

The chapter 3 of the book discovers details about each step, good questions to ask (to think about), DO’s and DONT’s. It also shows good example of the process of designing a news feed system.

A very short Chapter 2 is about how to make rough estimates to start from the most important parts when designing the software.

Some concepts that EVERY software developer should know:

• “Power of two”
• Standard latency numbers! How fast is memory, how slow is disk, etc…
• Availability numbers
• What are key metrics you should think about

These concepts and numbers are disclosed in chapter two of the book:

“System Design Interview – An insider’s guide” by Alex Xu

A great generic plan for scaling any app from zero to millions of users.

• Single server setup
• Selection and usage of database
• Vertical scaling vs horizontal scaling approaches. And why you should prefer horizontal
• Adding load balancer for horizontal scaling
• Adding database replication for horizontal scaling
• Adding cache
• Adding CDN
• Stateless vs Stateful architecture and using external state storage
• Adding extra Data Centers
• Adding Message queue
• Adding Logging, Metrics, and Automation
• Scaling database (sharding)
• and futher steps…

All of these is carefully but briefly disclosed in the Chapter 1 of the book: