Guiding Principles of the Architecture

First of all, the less moving parts we have, the less is the risk of one of them breaking. Consolidating two moving parts into one is usually a good idea.

To help you modify existing components, or to add a new one, these are the guiding principles that should be considered. An architecture component should be...

... the one way of doing a task

You shouldn’t have to stop and think about, which of the possible solutions is the best one. We should aim to have one blessed way of doing things, and make sure that all callsites are doing the same thing.

... testable

Of course, it should be possible to test the component. Not only in automated unit and integration tests, but also in a staging environment.

... scalable

A component is likely to have to do a lot of work, and the general load of Launchpad might change suddenly, so we need to design scalable components.

... upgradable with no apparent downtime for users

It should be possible to update the component’s code, without causing apparent downtime for users. For daemons, a good practice is to allow multiple daemons be running, so that you can always have one running, while updating the others. This also makes it possible to run multiple daemons on multiple machines, to avoid having a single point of failure.

... consistent with the rest of the architecture

All components should use the same code patterns, so that people already familiar with some of the architecture easier can understand how new components are used. For example, methods and attributes should be name in a similar manner.

... readable

By looking at the location and name of the architecture component, you should have some idea of what that component is actually doing.

... documented

You shouldn’t have to look at the implementation to figure out how to use something.