Architectural Solution - Distributed Caching to improve Performance and Scalability – Part 4

In Part 3 of this article series, I have detailed performance problems with few scenarios. The solution to achieve with custom distributed caching in Office 365 goes here.

With no control on the Office 365 topology, architects and developers are left with exploring other techniques to design more scalable and performance optimized solutions. Hardly there can be an architectural solution (which focuses on performance) without Caching considered in it. Following diagram illustrates the architectural solution to achieve Distributed Caching in Office 365.

On-premise caching:

Following are 2 major components when implementing the on-premise custom distributed caching:

Web service with caching APIs:

A service can be built with REST APIs like ListItem(), User() and Term() with all required caching policy parameters. In addition to these, use case specific (use cases which need very specific data to be returned) APIs can also be added. This service can be hosted in IIS or ConsoleApp or Windows service that best suits organization’s policies and requirements.

Windows Synchronization Service:

Synchronization component will play an important role in building the Cache. This can be a background process, such as windows service, that will invoke Office 365 APIs and builds the entities/objects to be cached. The business logic to boot the whole object system (objects to be cached) can be encapsulated in this component. Configuration based rule engine can be built to generate the entities in the cache.

Few important notes when implementing on premise solution:

  1. Remote event receivers can also be used to add/update/delete the Cached data.
  2. Use REST API design patterns to optimize service interfaces. Interface segregation principle is very important here.
  3. Availability, Fault Tolerance etc. are important aspects when hosting the caching service on-premise.
  4. Caching server can be scale out. Consider scale out strategy when designing the architecture.
  5. Choose Caching service hosting option very carefully. There are many attributes attached in choosing the hosting option like few enterprises may have ESB (Enterprise Service Bus) implemented as part of their SOA etc. etc. I am not going to detail all those here.
Microsoft Azure based caching service:

Most of things in Azure are similar to on-premise caching solution explained above. Two components in this case are:

Azure Caching service:

This is well tested by Microsoft and you don’t need to be worried about Availability, Fault tolerance etc. but all these goodies come at the cost. Whole documentation to implement this is available there on the internet, detailing that again isn’t needed here. With the increase in user base and content this server can be scale out too with MS taking care of most of the architecture quality attributes.

Worker Role:

Again, this is analogous to Cache Synchronization background process inthe on-premise solution. Most of the things that need to build on premise solution apply here too. Check the documentation available on the MSDN to implement Azure worker Role.