Designing Multi-Cluster Applications
GridGain and Apache Ignite customers follow a capability-maturity model as they become more familiarwith GridGain’s in-memory computing platform. When customers encounter the product, they often deploy it for simple caching use cases. At this simplest phase of maturity, the business case for GridGain is speed: the product is used to accelerate existing data access pipelines.But GridGain and Ignite offer customersmore than caching. And ascustomers’capability and maturity withthe product grow, they begin to use the product’s other features, like Compute Grid and Service Grid.
Some customers, however, go even further. At thehighest levels ofcustomer capability and maturity, the business case for GridGain and Ignite isn’t just speed and scale, but the ability to build systems that could not be built with competing products (or if they could, not on-time or in-budget).Among such advanced use cases are multi-cluster designs, where customersbuild enterprise applications overmore than one Ignite cluster.While complex, thesesystems have many advantages, including:
- Separation of concerns: by running multiple clusters, each cluster can fulfill its own distinct responsibilities, independent of other clusters in the system. Separation of concerns is exemplified by the popular CQRS design pattern (https://goo.gl/Lqdz6j).
- Orthogonal evolution: differentclusters can be upgraded and managed independently.
- Load compartmentalization: imagine a financial trading application with two Ignite clusters. One cluster listens to event streams of asset price changes (e.g., AAPL increased in value 4.5%) whereas the other cluster serves price data to the trading desk. If only one cluster were used, during periods of high market volatility, with many events coming in, data access for the trading desk would slow down, since both event processing anddata access are concentrated in one cluster. But this would notbe the case if two clusters were used, sincethe data access clusterserving the trading desk could continue to operate with tight SLAs regardless of the load on the event-listener cluster.
