"Small Twitter clone" can be taken two ways, and this one, I think, is the less interesting of the two. (Not to denigrate the project for what it is; it's a good idea.)<p>On a one-machine scale, Twitter can be a single Postgres table, or a single ElasticSearch index. At the scale they actually are, it's really a whole lot more.<p>I'd really love a tutorial—or possibly a whole book—that instead took you through setting up the sort of <i>distributed system</i> that is required to make a Twitter clone run at a Twitter-like scale. Either through IaaS APIs, or on your own with something like OpenStack DevStack.<p>It could probably <i>start</i> where this tutorial <i>ends</i>—with a one-node system running a Twitter-backend-alike monolith. And then each chapter would increase the scale, introduce a problem the scale causes, and then walk you through adding in an additional component: a message queue; a fragment cache; app-level health checks; a search indexing cluster; distributed logging + request tracing; geographic sharding; multi-master DB replication—in order to solve that scaling problem.<p>There would also be scale-points that would require changes in the business logic: making IDs globally unique and sortable ala <a href="https://github.com/twitter/snowflake;" rel="nofollow">https://github.com/twitter/snowflake;</a> deprecating but keeping around old APIs as new ones are added; "Ball of Mud" refactorings; isolated Enterprise clusters of the app; etc.<p>Bonus points if later chapters actually go back and rip out solutions that were introduced in earlier chapters—not because they were mistakes, but just because they were right for 10^3/s but not 10^6/s. And <i>bonus</i> bonus points if they assume an SLA that requires that such switchovers occur without downtime.