The objective of the NT project is to give you hands-on experience designing a simple system which will expose and exercise issues of scale. There is lot of room for creativity. There is a certain amount of guidance in the instructions, but you are welcome to diverge from it, and in fact in some places some interesting alternatives are presented.
The “spec” for NanoTwitter doesn’t dictate anything about the architecture. It is all specified from the outside in: NanoTwitter Functionality /. Beyond that specification, there’s no expectation that the product “look” like twitter. There’s wide freedom in the particular user interface. Our requirements are basic: good fit and finish, a workman like appearance, reasonbable usability. However there’s no expectation to go beyond that with fancy animation or similar decorations.
You will be using Ruby and Sinatra. The specified NanoTwitter Functionality / is not comprehensive. To make it complete you will have to fill in many blanks in fairly obvious places. Beyond that there’s lots of flexibility: certainly there are other databases than SQL, and there are other Caching services and Cloud services. The focus in the implementation will be on scalability, and application of as many of the scalability structures covered as possible, and even some not coverted. I recommend that you invest energy into making your product scale and not in making a fancy UI or adding extra features. As long as the functionality is as specified, anything is fair game.
NT will be deployed as a service in the cloud. Our base case is to use Heroku but again there are other variations that are possible which are equally valid. The NT code will have automated unit test that can be run at will to check for new bugs. The base case will be to use ruby’s minitest package.
In the quest for getting your product to scale it is easy to introduce bugs that are only revealed under load. Your cache algorithms may be buggy and have pages display with the wrong information (even though they look right superficially.) Or there may be problems with queue management which lead to data loss. There should be a serious attempt at good test coverage especially under load! Any tools that the team discovers to support the overall test, devops, and automation story are possible. In addition to writing and running tests, you will be using a continuous integration and testing service to make sure that you don’t deploy before running all your tests.
Teams that go beyond the core requirements will be recognized. There are lots of ways to go beyond the core, and recalling that the core-core goal is great scalability. Here are some other ideas, an incomplete list to be sure: