Site architecture - Relief-1/Relief1 GitHub Wiki
Site architecture
Overview
Our goal is to be the central point for all disaster management needs in the world, which means our site architecture must be able to stand the test. I prefer going through the process of designing this site from the ground up with the intention of it being a wild success. By spending time upfront ensuring(as much as possible) that we can withstand whatever hits us, whether it be the Slashdot effect or when playing a critical role in a disaster management situation, we can remove the anxious feelings we might feel if we were too hastily build the product only to fall to such onslaughts.
Philosophy
I am a belt and suspenders kind of person (I learned it from watching you Dad!). It is also my understanding that Murphy likes to wreak havoc at the least opportune time and that if something can break, it will break. We have to plan for nodes, datacenters, regions, and even entire continents to fail. It is imperative that our system take failures like these into account from the beginning so such situations do not catch us off guard.
Network Architecture
Letβs stand on the shoulders of giants and take advantage of the wide array of networking and datacenter solutions available to us via the cloud. The following requirements for a robust, fault-tolerant, and scalable system:
- Multiple Locations β Donβt put all your eggs in one basket
- Elastically Scalable Instances β Scale to meet demand
- Scalable Storage β Storage that scales to meet our needs
- CDN β Get data closer to the user
Software Architecture
In order to take advantage of this network architecture we must be utilize it properly. There many ways you can skin a cat and just as many to solve this problem, so we must decide what our requirements are. Our requirements are to have a system that is responsive, stable, secure and resource efficient.
Web Development Options
We want a solution that is:
- Event Driven
- Concurrent
- Fault Tolerant
- Stateless
- Distributed Model
- RESTful
- Security minded
- node.js seems like a perfect fit based on the following requirements, not only for the software stack, but because of the way it works with network architectures above. A web framework may be a good option to speed up time to market as well.
Databases
There are quite a few database options now; relational, key value stores, graphing, document, columnar, hybrids and more, each with their own strengths and weaknesses. A graphing database may be great for finding the relationship between people and places, but not so great at storing millions of notifications. We need to make our decision based on the previously described requirements and our use cases (how we model our data, etc).
Requirements
- Fault-tolerant β Designed to fail
- Replication β Easily replicates inside of a datacenter or across the world
- Scalability β Scales to meet demand
Options
- Riak β KVS, links & more
- CouchDB β Document Database
- Neo4J β Graphing Database
- PostgreSQL β Relational Database
- There are many other database options, thankfully Kristof has written up a SWAT analysis on quite a few databases.