nvartolomei

#System Design Interview Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

##Basic Steps

1. 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?

nvartolomei

The Case For Go

• Iron.io: How We Went from 30 Servers to 2 with Go
• Go at Google: Language Design in the Service of Software Engineering
• Behind the Scenes: Big Data at Torbit
• pool.ntp.org DNS server in Go
• Juju at Canonical
• Go at bitly
• NSQ: realtime distributed message processing at scale

nvartolomei

Title

<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>

• URL

  <The URL Structure (path only, no root url)>

• Method:

nvartolomei

Keybase proof

I hereby claim:

• I am nvartolomei on github.
• I am nvartolomei (https://keybase.io/nvartolomei) on keybase.
• I have a public key whose fingerprint is 3B0E 19E2 CD52 3E5F 7B3A 8FD6 843F 0F7C DC4A 1ADE

To claim this, I am signing this object:

nvartolomei

Internet Scale Services Checklist

A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."

• http://mvdirona.com/jrh/talksandpapers/jamesrh_lisa.pdf

Basic tenets

• Does the design expect failures to happen regularly and handle them gracefully?
• Have we kept things as simple as possible?