English | Portugus do Brasil Deutsch Italiano Polski Espaol Trke ting Vit Franais | Add Translation

---

---

Contributions

---

*****:*

:

• ****
• ****

Anki

:

****

Interactive Coding Challenges

• Coding deck

:

Contributing Guidelines

---

• :
  • Step 1:
  • Step 2:
• vs
• vs
• vs
  • CAP
    • CP - (consistency)(partition)
    • AP - (availability)(partition)
• (DNS)
• (CDN)
  • CDN
  • CDN
• • /
  • /
  • Layer 4
  • Layer 7
• (WEB)
  • vs
• • (RDBMS)
    • /
    • /
    • SQL
  • NoSQL
    • /
  • SQL or NoSQL
• • CDN
  • Web
  • • ()
• • (TCP)
  • (UDP)
  • (RPC)
  • Representational state transfer (REST)
• • 2

(short, medium, long)

*Q: *

*A: *

:

• **** - **** ****

• **** - **** ********

• **** - **** ********

| | | | | |---|---|---|---| | | :+1: | :+1: | :+1: | | | :+1: | :+1: | :+1: | | | :+1: | :+1: | :+1: | | | :+1: | :+1: | :+1: | | | Some | Many | Most | | | Some | Many | Most | | | Some | Many | Most |

open-ended conversation(Yes/No)

1:

2:

3:

url:

• URL
  • MD5 Base62
  • SQL NoSQL
• URLURL
• API &

4:

:

• 2

:

solutions/

| | | |---|---| | Pastebin.com ( Bit.ly) | | | Twitter (Facebook)
Twitter(Facebook) | | | | | | Mint.com | | | SNS | | | / | | | Amazon | | | AWS100 | | | | Contribute |

Pastebin.com ( Bit.ly)

Twitter& (Facebook&)

Mint.com

SNS

/

Amazon

AWS100

solutions/

*: *

| | | |---|---| | | | | LRU | | | | | | | | | | | | | | | | Contribute | | | Contribute |

:

1:

Harvard

• :

2:

• :

:

• **** vs ****
• **** vs ****
• **** vs ****

---

DNSCDN

vs

**** **** ¹

vs:

---

---

vs

---

---

---

• vs

vs

CAP

Source: CAP theorem revisited

:

• **** -
• **** -
• **** -

**

CP - (consistency and partition tolerance)

CP

AP - (availability and partition tolerance)

AP

• CAP
• CAP
• CAP FAQ

CAP

memcachedVoIP

()

DNS

RDBMS

: **** ****

IP

DNSIP

:

:

Source: DNS security presentation

(DNS) www.example.com IP

DNSISPDNSDNSDNSOStime to live (TTL)

• NS record (name server) - DNS
• MX record (mail exchange) -
• A record (address) - IP
• CNAME (canonical) - CNAME (example.com www.example.com) A record

CloudFlare Route 53 DNSDNS:

• • A/B

: DNS

• DNS
• DNSISP,
• DNSDDoS attackIPTwitter

• DNS
• Wikipedia
• DNS

(Content delivery network)

Source: Why use a CDN

(CDN)AmazonCloudFrontHTML/CSS/JSCDNDNS

CDN:

• CDN

CDN

CDNCDNURLCDN

CDNCDN

CDN

CDNCDNURLCDN

time-to-live (TTL) CDNCDN

CDNCDN

: CDN

• CDNCDN
• TTL
• CDNCDNURL

• CDNCDN
• Wikipedia

Source: Scalable system design patterns

:

() HAProxy

:

• SSL termination -
  • X.509 certificates
• **** -

:

• Least loaded
• /
• Layer 4
• Layer 7

Layer 4

Layer 4 IP Layer 4 Network Address Translation (NAT)

Layer 7

Layer 7 Layer 7 layer 7

layer 4 Layer 7

---

:

• • :
  • (SQL NoSQL) (Redis Memcached)

:

• NGINX
• HAProxy
• Wikipedia
• Layer 4
• Layer 7
• ELB listener config

(web)

Source: Wikipedia

:

• **** - IP
• **** - IP
• SSL termination -
  • X.509
• **** -
• **** -
• **** -
  • HTML/CSS/JS

vs

• NGINX HAProxy layer 7

:

• (: )

• vs
• NGINX
• HAProxy
• Wikipedia

Source: Intro to architecting systems for scale

() API

---

¹

Pinterest

Consul Etcd Zookeeper Health checks HTTP Consul Etcd key-value store

:

• Zookeeper

Source: Scaling up to your first 10 million users

(RDBMS)

SQL

ACID

• **** -
• **** -
• **** -
• **** -

: ** ** ** ** federation **** **** *SQL *

Source: Scalability, availability, stability, patterns

:

• **** :

Source: Scalability, availability, stability, patterns

:

• ACID
• **** :

:

:

Federation

Source: Scaling up to your first 10 million users

() **** **** ****

: federation

• server link

: federation

• Scaling up to your first 10 million users

Source: Scalability, availability, stability, patterns

federation

:

• SQL
• • consistent hashing

:

• Consistent hashing

RDBMSPostgreSQL Oraclematerialized views

100110001

:

:

• Denormalization

SQL

SQL

---

• **** - ab
• **** - slow query log

• MySQL
• VARCHAR CHAR
  • CHAR VARCHAR
• TEXT TEXT TEXT
• 23240 INT
• DECIMAL
• BLOBS
• VARCHAR(255) 8DBMS1
• NOT NULL

• (SELECT GROUP BY ORDER BY JOIN)
• BB

: SQL

• MySQLTips
• VARCHAR(255)
• null
• Slow query log

NoSQL

NoSQL key-value store document-store wide column store graph databaseNoSQLACID

BASE NoSQLCAP Theorem BASE

• Basically available -
• Soft state -
• **** -

SQLNoSQL NoSQL **** **** **** ****

:

O(1)SSD

:

• Redis

:

(XML JSON binary)API **

MongoDB CouchDB SQLDynamoDB

:

• MongoDB
• CouchDB
• Elasticsearch

Source: SQL & NoSQL, a brief history

: < <ColKey Value Timestamp>>

SQL

GoogleBigtableHadoopHBase FacebookCassandra BigTableHBaseCassandra

:

• SQL & NoSQL
• Bigtable
• HBase
• Cassandra

Source: Graph database

:

SNSREST APIs

:

• Graph
• Neo4j
• FlockDB

: NoSQL

• NoSQL
• NoSQL
• NoSQL

SQLNoSQL

Source: Transitioning from RDBMS to NoSQL

SQL :

NoSQL :

• TB ( PB)
• IOPS

NoSQL:

• ('')

: SQLNoSQL

• 1000
• SQLNoSQL

Source: Scalable system design patterns

OS

CDN

CDN

Web

Varnish web

In-memoryRedisRAMRAMleast recently used (LRU)cache invalidation '' '' RAM

Redis:

: **** **** :

• Fully-formed serializable objects
• Fully-rendered HTML

:

:

• :

:

Source: From cache to in-memory data grid

:

python def get_user(self, user_id): user = cache.get("user.{0}", user_id) if user is None: user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id) if user is not None: key = "user.{0}".format(user_id) cache.set(key, json.dumps(user)) return user

Memcached

:

• time-to-live (TTL)

Source: Scalability, availability, stability, patterns

:

set_user(12345, {"foo":"bar"})

:

python def set_user(user_id, values): user = db.query("UPDATE Users WHERE id = {0}", user_id, values) cache.set(user_id, user)

:

• TTL

()

Source: Scalability, availability, stability, patterns

:

:

Source: From cache to in-memory data grid

:

:

• cache invalidation
• Redismemcached
• Cache invalidation

• From cache to in-memory data grid
• AWS ElastiCache
• Wikipedia

Source: Intro to architecting systems for scale

:

Redis

RabbitMQ 'AMQP'

Amazon SQS

Celery python

HTTP 503exponential backoff

:

• It's all a numbers game
• Little's law

Source: OSI 7 layer model

Hypertext transfer protocol (HTTP)

HTTP HTTP

HTTPHTTP()()HTTP:

| | | * | | | |---|---|---|---|---| | GET | | Yes | Yes | Yes | | POST | | No | No | Yes | | PUT | | Yes | No | No | | PATCH | | No | No | Yes | | DELETE | | Yes | No | No |

**

HTTPTCP UDP

: HTTP

• HTTP?
• HTTP TCP
• PUT PATCH

(TCP)

Source: How to make a multiplayer game

TCPIP networkhandshake:

• checksum fields
• Acknowledgement

TCP UDP

TCPmemcached UDP

TCPSMTPFTPSSH

UDPTCP:

(UDP)

Source: How to make a multiplayer game

UDPUDPTCPUDPTCP

UDPDHCP IPIPTCP

UDPVoIP

TCPUDP:

: TCP UDP

• TCP UDP
• TCP UDP
• Transmission control protocol
• User datagram protocol
• Facebook

(RPC)

Source: Crack the system design interview

RPCRPCRPCProtobuf ThriftAvro

RPC :

• **** -
• **** - ID
• **** - OS
• **** - OS
• **** - ID

Sample RPC calls:

``` GET /someoperation?data=anId

POST /anotheroperation { "data":"anId"; "anotherdata": "another value" } ```

RPCRPC

(aka SDK) :

REST HTTP APIAPI

: RPC

• RPC
• API
• RPC
• SquidRPC

Representational state transfer (REST)

REST

RESTful :

• ** (URI in HTTP)** - URI
• HTTP (Verbs in HTTP) -
• ** (status response in HTTP)** -
• HATEOAS (HTML interface for HTTP) - web

REST :

``` GET /someresources/anId

PUT /someresources/anId {"anotherdata": "another value"} ```

RESTAPIRESTURI representation through headersGETPOSTPUT DELETEPATCHHTTPREST

: REST

• RESTRESTURI
• REST(GETPOSTPUTDELETE PATCH)
• API

RPCREST

| Operation | RPC | REST | |---|---|---| | | POST /signup | POST /persons | | | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Person | GET /readPerson?personid=1234 | GET /persons/1234 | | Person | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Person | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Source: Do you really know why you prefer REST over RPC

: REST RPC

• Do you really know why you prefer REST over RPC
• When are RPC-ish approaches more appropriate than REST?
• REST vs JSON-RPC
• Debunking the myths of RPC and REST
• What are the drawbacks of using REST
• Crack the system design interview
• Thrift
• Why REST for internal use and not RPC

contributing

• XSS SQL injection
• SQL injection
• least privilege

:

• OWASP top ten

1002 ****

2

```

Bytes

7 128 8 256 10 1024 1 thousand 1 KB 16 65,536 64 KB 20 1,048,576 1 million 1 MB 30 1,073,741,824 1 billion 1 GB 32 4,294,967,296 4 GB 40 1,099,511,627,776 1 trillion 1 TB ```

:

• 2

```

Latency Comparison Numbers

L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns 14x L1 cache Mutex lock/unlock 25 ns Main memory reference 100 ns 20x L2 cache, 200x L1 cache Compress 1K bytes with Zippy 10,000 ns 10 us Send 1 KB bytes over 1 Gbps network 10,000 ns 10 us Read 4 KB randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD Read 1 MB sequentially from memory 250,000 ns 250 us Round trip within same datacenter 500,000 ns 500 us Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip Read 1 MB sequentially from 1 Gbps 10,000,000 ns 10,000 us 10 ms 40x memory, 10X SSD Read 1 MB sequentially from disk 30,000,000 ns 30,000 us 30 ms 120x memory, 30X SSD Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms

Notes

1 ns = 10^-9 seconds 1 us = 10^-6 seconds = 1,000 ns 1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns ```

:

• 30 MB/s
• 1 Gbps Ethernet100 MB/s
• SSD 1 GB/s
• main memory 4 GB/s
• 16-7
• 12000

:

• - 1
• - 2
• Designs, lessons, and advice from building large distributed systems
• Software Engineering Advice from Building Large-Scale Distributed Systems

| | | |---|---| | Dropbox | youtube.com | | Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Googleweb | quora.com | | Google docs | code.google.com
neil.fraser.name | | Redis | slideshare.net | | Memcached | slideshare.net | | Amazon | hulu.com
ijcai13.org | | BitlyURL | n00tc0d3r.blogspot.com | | WhatsApp | highscalability.com | Instagram | highscalability.com
highscalability.com | | Facebook | quora.com
quora.com
slideshare.net | | Facebook | facebook.com
highscalability.com | | Facebook | erlang-factory.com
facebook.com | | Facebookgraph | facebook.com
facebook.com
facebook.com | | CloudFlareCDN | cmu.edu | | Twitter | michael-noll.com
snikolov .wordpress.com | | ID | blog.twitter.com
github.com | | k | ucsb.edu
wpi.edu | | | highscalability.com | | | indieflashblog.com
buildnewgames.com | | | stuffwithstuff.com
washington.edu | | | Contribute |

Source: Twitter timelines at scale

---

| | | | |---|---|---| | | MapReduce - Google | research.google.com | | | Spark - Databricks | slideshare.net | | | Storm - Twitter | slideshare.net | | | | | | | Bigtable - Google | harvard.edu | | | HBase - Bigtable | slideshare.net | | | Cassandra - Facebook | slideshare.net | | DynamoDB - Amazon | harvard.edu | | | MongoDB - | slideshare.net | | | Spanner - Google | research.google.com | | | Memcached - | slideshare.net | | | Redis - | slideshare.net | | | | | | | Google File System (GFS) - | research.google.com | | | Hadoop File System (HDFS) - GFS | apache.org | | | | | | Misc | Chubby - Google | research.google.com | | Misc | Dapper - | research.google.com | Misc | Kafka - LinkedInPub/sub | slideshare.net | | Misc | Zookeeper - | slideshare.net | | | | Contribute |

| | | |---|---| | Amazon | Amazon architecture | | Cinchcast | Producing 1,500 hours of audio every day | | DataSift | Realtime datamining At 120,000 tweets per second | | DropBox | How we've scaled Dropbox | | ESPN | Operating At 100,000 duh nuh nuhs per second | | Google | Google architecture | | Instagram | 14 million users, terabytes of photos
What powers Instagram | | Justin.tv | Justin.Tv's live video broadcasting architecture | | Facebook | Scaling memcached at Facebook
TAO: Facebooks distributed data store for the social graph
Facebooks photo storage | | Flickr | Flickr architecture | | Mailbox | From 0 to one million users in 6 weeks | | Pinterest | From 0 To 10s of billions of page views a month
18 million visitors, 10x growth, 12 employees | | Playfish | 50 million monthly users and growing | | PlentyOfFish | PlentyOfFish architecture | | Salesforce | How they handle 1.3 billion transactions a day | | Stack Overflow | Stack Overflow architecture | | TripAdvisor | 40M visitors, 200M dynamic page views, 30TB data | | Tumblr | 15 billion page views a month | | Twitter | Making Twitter 10000 percent faster
Storing 250 million tweets a day using MySQL
150M active users, 300K QPS, a 22 MB/S firehose
Timelines at scale
Big and small data at Twitter
Operations at Twitter: scaling beyond 100 million users | | Uber | How Uber scales their real-time market platform | | WhatsApp | The WhatsApp architecture Facebook bought for $19 billion | | YouTube | YouTube scalability
YouTube architecture |

• Airbnb Engineering
• Atlassian Developers
• Autodesk Engineering
• AWS Blog
• Bitly Engineering Blog
• Box Blogs
• Cloudera Developer Blog
• Dropbox Tech Blog
• Engineering at Quora
• Ebay Tech Blog
• Evernote Tech Blog
• Etsy Code as Craft
• Facebook Engineering
• Flickr Code
• Foursquare Engineering Blog
• GitHub Engineering Blog
• Google Research Blog
• Groupon Engineering Blog
• Heroku Engineering Blog
• Hubspot Engineering Blog
• High Scalability
• Instagram Engineering
• Intel Software Blog
• Jane Street Tech Blog
• LinkedIn Engineering
• Microsoft Engineering
• Microsoft Python Engineering
• Netflix Tech Blog
• Paypal Developer Blog
• Pinterest Engineering Blog
• Quora Engineering
• Reddit Blog
• Salesforce Engineering Blog
• Slack Engineering Blog
• Spotify Labs
• Twilio Engineering Blog
• Twitter Engineering
• Uber Engineering Blog
• Yahoo Engineering Blog
• Yelp Engineering Blog
• Zynga Engineering Blog

:

• kilimchoi/engineering-blogs

kilimchoi/engineering-blogsengineering-blogs

!

• MapReduce
• Consistent hashing
• Scatter gather
• Contribute

Special thanks to:

• Hired in tech
• Cracking the coding interview
• High scalability
• checkcheckzz/system-design-interview
• shashank88/system_design
• mmcgrana/services-engineering
• System design cheat sheet
• A distributed systems reading list
• Cracking the system design interview

Contact info

Feel free to contact me to discuss any issues, questions, or comments.

My contact info can be found on my GitHub page.

License

I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/