BloomReach Experience Manager is designed to scale and provides an architecture that can handle your evolving traffic requirements now and in the future.
At system architecture level, BloomReach Experience Manager scales out very well. Each of its 3 tiers can be scaled individually. The web tier can run a load-balancer with multiple web servers serving as reverse proxies. In the application tier, any number of application servers can be clustered and because authoring and delivery applications are separated, these can be individually clustered as well. The database tier can consist of a single database server, a cluster of database servers, or master/slave setup1.
A BloomReach Experience Manager application cluster is managed through a journal table in the database which allows individual nodes to keep their content repositories in sync, and newly added nodes to ‘catch up’ automatically. This allows a fast response to quickly evolving traffic requirements simply by adding or removing nodes.
The load-balancer needs to be able to handle sticky sessions for the authoring webapp. The delivery webapp normally does not have this requirement if best practices are followed, although this is up to the implementation.
At application level BloomReach Experience Manager’s delivery framework scales up very well too. Through efficient use of available hardware resources and smart caching strategies the number of concurrent requests that can be handled scales linearly with increased CPU speed and number of CPU cores. Especially in a virtualized environment this provides an additional way to respond quickly to changing traffic requirements.
1 BloomReach Experience Manager must be connected to (only) the active or master database.