Attention: if you attempt to fork this gist, github will think that you are a spammer and you will have to confirm that you are human with them. Apparantly there are too many links in this list. Also I update it rather frequently (see revisions on the left), so it's probably wise to not fork it anyway.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 3,000 ns | |
Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms | |
Read 4K randomly from SSD 150,000 ns 0.15 ms | |
Read 1 MB sequentially from memory 250,000 ns 0.25 ms | |
Round trip within same datacenter 500,000 ns 0.5 ms |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/** | |
* A "Left-leaning Red-Black Tree" | |
* | |
* http://www.cs.princeton.edu/~rs/talks/LLRB/LLRB.pdf | |
*/ | |
public class LLRB<K extends Comparable<K>, V> { | |
public static void main(String[] args) { | |
LLRB<String, String> llrb = new LLRB<String, String>(); | |
ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats
#System Design Interview Cheatsheet
Picking the right architecture = Picking the right battles + Managing trade-offs
##Basic Steps
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
- Does the design expect failures to happen regularly and handle them gracefully?
- Have we kept things as simple as possible?