Databases Reference
In-Depth Information
Notes on Scalability and Availability
The architecture of this solution has been simplified to fit into a single chapter of the
topic. For that reason, you avoided some complexity that would be necessary for this
solution to scale and have high availability. There are a couple of major issues with this
approach.
The Redis server in this architecture is not only a
single point of failure
but also a bot-
tleneck. You'll be able to receive only as much traffic as the Redis server can handle.
The Redis layer can be scaled by using sharding, and its availability can be improved
by using a Master/Slave configuration, which would require changes to the sources of
both the topology and the web application.
Another weakness is that the web application does not scale proportionately by adding
servers in a round robin fashion. This is because it needs to be notified when some
product statistic changes and to notify all interested browsers. This “notification to
browser” bridge is implemented using Socket.io, but it requires that the listener and
the notifier be hosted on the same web server. This is achievable only if you shard the
GET /product/:id/stats
traffic and the
POST /news
traffic, both with same criteria, en-
suring that requests referencing the same product will end up on the same server.
