SCRAP Framework


SCRAP (courtesy of

Scalability (plan for growth)

  • Use homogeneous networks. Don’t mix vendor networking gear
  • If you can’t split it, you can’t scale it (Randy Shoup)
  • Sharding is one way to scale data stores
  • Master/slave replication has trade-off (master SPOF)
  • Scale out and concurrency are antidotes to Moore’s law

Complexity (plan for humans)

  • Break down complexity into units (engines)
  • Focus on essential complexity, not accidental complexity
  • Break down scope into minimum viable functionality
  • Design until you have no more features to eliminate
  • Visualize graph of interfaces, not UML

Resiliency (plan for failure)

  • Use commodity hardware (goldfish, not thoroughbreds)
  • Actively use log files
  • Recreate data from transaction logs
  • Use version control for change management
  • Master your emergency drills
  • Avoid single points of failure


API (plan for integration)

  • Hide complexity behind a simple and minimal interface
  • Move data, not logic
  • Composition over inheritance
  • Service (verb) is for writes. Resource (noun) is for reads
  • Design interface with replaceable components (wire on/wire off)

Performance (plan for execution)

  • Reduce DNS lookups
  • Reduce objects where possible
  • Use caching where appropriate
  • Firewalls may be unnecessary hop for intranet IPC
  • Measure twice and cut once (unnecessary error checking)
  • Use asynchronous operation, no two-phase commit



Subjectivity aside, leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s