Facebook's Product Infrastructure • Adam Wolff • YOW! 2015

Product development at Facebook follows a “hacker process” focused on rapid iteration, measurement, and shipping small changes frequently rather than big rewrites

Infrastructure should be viewed as a projection of capabilities forward in time - shared ideas about how to enable future functionality even before it exists

Traditional patterns like REST and SQL have limitations in distributed systems. Facebook developed alternatives like GraphQL to let clients specify exactly what data they need

Runtime feature gating and experimentation are critical - nearly every new feature is protected by runtime gates that allow gradual rollout and measurement of impact

Careful measurement and metrics are essential for product development - as much effort goes into measuring feature impact as building the features themselves

The fastest way to build great products is through rapid iteration cycles, not extensive upfront planning. Ship small changes quickly and measure results.

Facebook maintains a single master branch with no feature branches. All code goes to master and ships in weekly releases.

Product teams should optimize for making systems resilient to changes/breaks rather than trying to prevent all breaks

Complex products have multiple user types beyond just end users - advertisers, operations teams, developers etc. all have different needs

Simple architectures that work (“sharks”) often outlast more sophisticated designs. Focus on solving real problems over architectural elegance.