Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Stabilizing the npm registry
Search
C J Silverio
February 11, 2015
Programming
410
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Stabilizing the npm registry
How npm went from a car fire to a very boring service with a very boring uptime.
C J Silverio
February 11, 2015
More Decks by C J Silverio
See All by C J Silverio
The economics of package management
ceejbot
4
1.6k
The future of (javascript) modules (in node)
ceejbot
1
340
Keeping JavaScript safe
ceejbot
3
500
ceej's how to solve it
ceejbot
6
790
work-life balance at npm
ceejbot
5
810
hash functions and you!
ceejbot
2
390
The accidental noder
ceejbot
2
190
Design Patterns & Modularity in the npm Registry
ceejbot
3
220
Monitoring on a budget
ceejbot
2
310
Other Decks in Programming
See All in Programming
AGENTS.md Is Not Enough:Build Skills, Don't Download Them
lx_t
0
130
仕様駆動開発による爆速プロダクト開発 / Bakusoku Spec Driven Development
kobakei
0
130
[GoCon2026] When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go
takehaya
6
2.4k
巨大モノリシックアプリ モダン化大作戦
ktcryomm
1
1.1k
Augmenting AI with the Power of Jakarta EE
ivargrimstad
0
250
Verilogで学ぶCPU自作入門.pdf
uyuki234
2
1.2k
Starting & Sustaining Code-Based E2E Testing for Non-Coding QA Teams( #jasstniigata )
teyamagu
PRO
1
500
XP祭りでしか伝わらないフリップネタ #xpjug
murabayashi
0
150
App Intentsのビルドプロセスを支える技術
kntkymt
0
420
パズルゲームの作り方 / how to make puzzle games
kaityo256
PRO
2
150
Go × SIMDで高速化するベクトル検索 ~ルーフラインモデルでSIMDが効く境界を探れ! ~
po3rin
1
2.8k
手動確認はもう限界 〜XCUITestでCustom URL Schemeの遷移を起動種別ごとに自動テストする〜 / Testing Custom URL Schemes with XCUITest
otouto
0
330
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.8k
KATA
mclloyd
PRO
35
15k
A Modern Web Designer's Workflow
chriscoyier
699
190k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
570
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
310
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
380
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Visualization
eitanlees
152
17k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
2k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
Transcript
stabilizing the registry
C J Silverio director of engineering, npm @ceejbot
This is the story of a plucky package registry named
npm
scaling problem manifesting itself as a stability problem
"scaling" capacity to meet growing demands
"At scale" huge demand & lots of data
"stability" not falling over under normal demand
What's normal demand?
129K packages 239 GB package tarballs 40 million pkg dls/day
1500 req/sec, peak 3200
"Legacy" Anything you've put into production
this is the story of a legacy system becoming more
flexible
None
January 2013 20K packages .5 million dls/day
Oct 2013 44K packages 108 million dls/month 3.6 million dls/day
None
our plucky little registry had to change
step 1: CDN Put Fastly.com in front of the registry
cache rules everything around me
step 2: tarballs get them out of couchdb
tarballs are huge! couch runs better without them base64 decoding
is work.
None
January 2014 60K packages 6+ million dls/day
step 3: visibility are things going wrong? what's going wrong?
reactive monitoring monitor deeply fix things quickly
proactive monitoring self-healing (also things don't break)
monitoring is unit testing Add monitoring after every outage
visibility is a prerequisite but not a solution
act on what monitoring and metrics reveal
step 4: redundancy several CouchDBs! reads, writes, & replication
fewer responsibilities for each piece isolates errors
step 5: automation ansible no server is special
June 2014 Superficially similar.
June 2014 80K packages 10 million dls/day
step 6: simplification now that it's not on fire we
can modify at leisure
None
Nov 2014 105K packages 28 million dls/day peak
50/50 AWS region split no AWS-specific magic Ubuntu 14.04 Trusty
Fastly: geoloc + varnish haproxy + CouchDB nginx + a
filesystem
where's the node?
registry 2 electric boogaloo with 500% more node
None
haproxy + node services couchdb ➜ postgres redis for caching
nginx + filesystem
more complicated more flexible & redundant more scaling dials to
turn
excited about postgres ad-hoc queries are fun
scaling node is exactly like scaling everything else
Understand system get visibility cool down hot spots add redundancy
npm client <3 npm install -g npm@latest
npm loves you