The Problem
Incremental feature development against existing systems frequently involves rethinking and rebuilding existing components. If it’s possible, the easiest way to add support for your new feature is to introduce a new, optional attribute on a model (or in the case of a relational database, adding a NULLable column to an existing table, or adding a new table). Sometimes, though, that either isn’t possible, or wouldn’t be the best design going forward, given your new knowledge of the feature set of the product at hand. You’re left with the uncomfortable realization that the best design would be something completely different that isn’t backward-compatible with current systems.
When there are multiple systems that consume a given data model (say, a front-end webserver, an API, tons of cron jobs, and many backend daemons, like in the case of Twitter’s Ads systems), you can’t just “stop the world,” ALTER your tables, and deploy all the new code. That’s fine if it’s you and another nerd in a garage, but when you’ve got paying customers, you don’t want to give them an excuse to spend their money elsewhere.
What to do?
Read more ›