Server

Compact Architecture with Redis

Updated: April 29, 2024

Architecture Description

In this architecture:

  • A load balancer with sticky sessions is used.
  • A total of two machines are prepared for the application cluster. Each machine holds a Nuxeo server node, a Redis node, and a reverse proxy. More machines can be added later for scalability purpose.
  • Since we have two Redis nodes, we take advantage from it to configure Redis in master / slave mode.
  • An Elasticsearch cluster with at least 3 nodes.
  • A database cluster with at least 2 nodes.
  • Chronicle Queue as the default implementation for Nuxeo Stream.

1-basic-architecture.png
1-basic-architecture.png

This architecture can be improved by externalizing the Redis node inside a specific cluster:

1-basic-architecture-v2.png
1-basic-architecture-v2.png

Limitations

As detailed in the messaging system page this is not a recommended solution because:

  • The processing done with the Bulk Service relies on Chronicle Queue which is not distributed (poor performance) and not fault tolerant.
  • The WorkManager Queuing is limited by the amount of Redis memory and in case of failure Works might be lost.

→ Jump to the Compact architecture with Kafka to:

  • Remove Redis and Chronicle Queue limitations
  • Benefits from Kafka advantages