Skip to main content

EVA Architecture

docs image

EVA Architecture

EVA's architecture in a nutshell

This page provides an overview of EVA's architecture. The tech structure, how it functions, events and messaging, open source frameworks used, and more.


Microservices and their bounded context​

EVA is not a microservice platform. The core of EVA platform offers all available functionalities but can be surrounded by separate (micro)services that provide additional functionalities or enhance existing ones. The EVA platform is designed to effortlessly adopt the latest backend applications, frontend frameworks, and innovative solutions.

API’s with descriptive endpoints​

You can explore the EVA API using the Service Explorer tool known as DORA.

API reference

A list of all services: API reference

Technical tenant structure for multi-tenant setups​

To support multi-tenant set-ups, EVA follows these principles:

  • Every EVA tenant is hosted separately, meaning no resources or data structures are shared between our customers. Environments (development, test and staging) are kept completely separated. However, some processing resources may be shared within your organization environments (for example, between your development and test environments).
  • Environments within EVA are scripted for swift and easy deployments.
  • Hierarchical Organization structure, such as region, country, and store, can be designed within EVA environments. This hierarchy facilitates permission controls and role management.
  • Authentication can be based on the default EVA authentication mechanism, but can also be linked to external parties (OAuth/OpenID).
  • EVA environments can be hosted in a multi-region setup, where one region serves as the primary source of truth for your organization setup and settings. Other regions, known as Slave regions, can then function independently and periodically report transactions to the Master region.
  • Users can be allowed to act globally and log in to every region (Single Sign-On). This flexibility extends to other data aspects, all tailored to support your specific business requirements.

Event architecture​

EVA is an event and message driven platform. Nearly every API request generates one or more (event) messages distributed through the message-broker (RabbitMQ). Consumers in the core application or add-ons (Plugins) can act on these messages, enhancing core functionality.


Orchestration patterns used for microservices​

EVA is a “Contextual” driven service platform. Services are orchestrated based on context and depend on context within the named processes. For example, “add a product to the shopping basket” triggers new processes to validate order and customer requirements. As a result, microservices in EVA aren't orchestrated like those in a typical microservices platform.

You can explore this setup in the SDK and DORA documentation.

Open source frameworks and rationale​

The EVA platform is built with the best of technology available, which is why the core uses a variety of open source frameworks and libraries.

  • Elasticsearch: The standard for searching documents, supporting product catalog (PIM) searches, order processing, user databases, and more. Every change in any of those is mirrored to Elastic for fast and convenient searching.
  • Redis: A fast key-value store used for user session data and short-lived caching.
  • RabbitMQ: The foundation of EVA's eventing and messaging architecture.

Release Cycle​

Over time, EVA has grown into an extensive set of applications and modules. Although not all facets adhere to the same release schedule, they are consistently released and in a timely manner.

Releases are published centrally for all customers, allowing them to review the release notes for the latest versions, updates, and deprecations. The following four frontend functionalities are released uniformly:

More on release cycles can be found in the Introduction to releases page.

Latest and greatest

Customers will have a full release (four weeks) to update their versions, adopt the applicable changes introduced, and are allowed to be one release behind on our 'lastest-and-greatest'.