Monday, 5 August 2013

Scalable Services

Previously, I mentioned about micro service architecture and its features, This time I will mention about scaling services and try to explain design strategies that affect scalability of  services.
Nowadays every business wants to have easily scalable services. Because today’s business environment is more competitive and customers are more demanding, no one wants to wait for a long web page load, will use a slow mobile application. it’s also important to maintain customer retention policy, today’s customers have more choices compared to the past, so scalable high performing services are paramount to any business success.
By scalability, I mean scaling whole technology stack a service use. A truly scalable service architecture requires avoiding any kind of bottleneck whether it is in the application or database layer.
I will focus on scaling applications via partitioning service consumers. Easiest way of scaling services is making them data agnostic and have load balancers distributing traffic randomly between service instances so that each instance can serve a range of traffic received. We can see this strategy applied in Cassandra random partitioner and MongoDB hash based sharding.

scalable service
Scalable service

While that strategy works most of the time, there are occasions that a service needs to treat received traffic in a smarter way, which may require examining the received traffic data, before processing the request, for example a payment card processing system can distribute the received traffic amongst service instances according to card BIN numbers, which ensures a customer bank’s data goes into the same instance every time. That strategy is an application of reactor pattern at architecture level. A front controller or load balancer can examine the initial piece of the traffic data, then delegate work to a specific instance. Another example is that some service features could depend on customer’s geo-location for tax, jurisdiction purposes.
Reactor pattern, applied at architectural level, also helps to abstract specific traffic types and build specialized versions of service instances. For example once jurisdiction is abstracted, a service can have either a UK or AUS jurisdiction instance supplied during service provisioning. That strategy enables treating service traffic selectively rather than randomly hence yields control of the received traffic.

No comments:

Post a comment