Section 1
Platform Overview
About This Document
This document describes the software architecture of the Infosys Equinox Commerce Platform version 9.x. It supersedes the prior architecture reference, which described a four-layer model (Presentation → Orchestration → Microservices → Persistence). In 9.x, the dedicated Orchestration Layer has been removed and its responsibilities have been internalized within each microservice through the ACTION API pattern.What is Infosys Equinox?
Infosys Equinox is a microservices-based digital commerce platform that is both flexible and easily extensible. It implements MACH-X technology — Microservices, API-first, Cloud-native, and Headless — designed to address the ever-evolving demands of digital commerce without vendor or infrastructure lock-in.
What’s New in 9.x?
Equinox 9.0 delivers a simplified, serverless architecture with fully managed infrastructure and infinitely scalable microservices. A rich plugin ecosystem extends commerce capabilities while preserving backward compatibility across upgrades. Backstage integration powers an Equinox Developer Portal with golden paths, service scaffolding, and unified observability. AI-based SDLC embeds intelligence into pipelines, testing, and operations — making every commit production-ready by default. Feature flags progressively expose value safely and continuously, without environment sprawl. Together, these core 9.x capabilities redefine how commerce platforms are built, operated, and evolved at scale.
Section 2
MACH-X Design Principles
Infosys Equinox 9.x continues to implement the MACH-X architectural principles established in earlier platform versions. These principles guide every technology decision in 9.x.
Microservices-based Architecture
Services are segregated by Sub-Domain (Domain Driven Design). Each microservice is independently deployable, scalable, and has its own persistence and caching boundary. No direct REST-based inter-service communication — all such interactions happen asynchronously or through the ACTION API pattern.
Cloud-Native
Born in the cloud and designed to take full advantage of cloud power and flexibility. Follows 12-factor App methodologies. All tools and frameworks are selected to use Cloud Services where available, enabling elastic scaling and managed infrastructure.
Cloud-Agnostic
Designed and built to run on any major cloud provider — Amazon Web Services, Microsoft Azure, or Google Cloud Platform — with no IaaS vendor lock-in. On-Premise deployment remains supported.
API-First / Headless
Equinox exposes scalable Storefront and administrative APIs. In 9.x, each microservice surfaces its own ACTION APIs, providing a single-step data aggregation entry point per domain without an intermediary orchestration tier.
Section 3
Architecture Overview
The 9.x architecture is a three-layer model. The dedicated Orchestration Layer present in earlier versions has been eliminated. Data aggregation and business logic composition are now handled internally within the Microservices Layer through the ACTION API pattern.
Infosys Equinox – Architecture Overview Presentation Layer React based storefront. Reference implementation provided as an accelerator and gets customized for each client. B2C/ B2B / B2B2C Storefront Admin Portal React based business tooling providing capabilities to the Business Users. Capabilities include catalog, price, promotion setup and managing orders and customer. Micro front-ended admin application. Microservices Layer NodeJs – Fastify based Microservices ACTION Apis that ties various services together. Serves as a central place for customer specific business logic and an integration point for third party or client’s in-house Microservices. MS MS MS MS MS MS MS Allows plugin-based extension model. Third party vendor plugins can be created and deployed along side these Microservices/APPs. MS MS MS MS MS MS MS Framework Persistence Layer Document Based (NoSQL) Database to store transactional and non-transactional information. Also uses Redis for caching and Amazon OpenSearch (AWS) for search with faceting capabilities. Database and In-Memory Storage
Key Architectural Change from Previous Versions
In versions prior to 9.x, an explicit Orchestration Layer (built on Apache Camel + Spring Boot) sat between the Presentation and Microservices layers, aggregating multiple microservice calls into a single API response. In 9.x this layer is removed. Each microservice now contains its own ACTION APIs that handle data aggregation internally, reducing hops and simplifying deployment topology.Section 4
Presentation Layer
The Presentation Layer is the entry point into the Infosys Equinox Commerce platform for both business administrators and storefront customers. When accessing the platform in headless mode, the presentation layer is bypassed and the Microservices ACTION APIs are consumed directly.
🏪
Storefront (B2C / B2B / B2B2C)
- Reference storefront used by end-users for commerce transactions
- Built using the React Framework on NodeJS, with reusable, atomic, and modular design patterns
- Supports B2C, B2B, and B2B2C business models — accelerator implementations customized per client
- Rapid development without interfering with backend microservice code
- Communicates directly with Microservices ACTION APIs (no separate orchestration hop)
- Capabilities: Browse catalog, product search with facets, cart, checkout, order management, user account
- Can be used headlessly — presentation layer is optional for headless integrations
🛠️
Admin Portal
- React-based micro front-end admin application — each business tool is an independently bootable module
- Provides capabilities to Business Users for managing master data
- Forwards requests directly to Microservices ACTION APIs in 9.x
- Managed domains include: Businesses, Stores, Catalog (Products & SKUs), Categories, Pricing, Promotions, Orders, Users
- Sprint Boot / Thymeleaf dependency removed — fully React-based in 9.x
New in 9.x Micro front-end admin architecture
Section 5
Microservices Layer
The Microservices Layer is the core component of the Infosys Equinox 9.x Commerce Platform. It provides all business logic through a distributed set of domain-aligned microservices built on NodeJS and the Fastify framework. Services are grouped into three categories: Non-Transactional Services (led by PIM — the single service for catalog, categories, and price), Transactional Services (commerce operations requiring state management), and Inbuilt Apps (platform-bundled capabilities such as Payment, Search, Shipping, Tax, Address, and Notification).
NodeJS + Fastify Runtime
All microservices in 9.x are built on NodeJS with the Fastify framework, replacing the Java/Spring Boot runtime used in prior versions. Fastify provides a high-performance, low-overhead HTTP server ideal for microservice workloads, with a rich plugin ecosystem and built-in schema validation.Domain-Driven Decomposition
Services are decomposed by business capability (DDD Bounded Context). Each microservice owns its domain data, logic, and persistence independently. There is no direct REST inter-service communication — interactions are asynchronous or through the internal ACTION API pattern.
Plugin-Based Extension Model
The platform allows plugin-based extensions. Third-party vendors and client teams can create and deploy plugin microservices alongside the core platform microservices without modifying platform code. Plugins are registered via the Plugin SDK.
Shared Framework
A shared framework layer provides common cross-cutting concerns: authentication middleware, logging, distributed tracing, event bus integration, schema validation, and the Plugin SDK. Each microservice inherits these capabilities without duplicating them.
Non-Transactional Services
These services manage reference and catalog-type data where strong transactional guarantees are not required. PIM is the single unified service covering catalog, categories, and price — there are no separate Catalog, Merchandise, or Price microservices.
PIM Promotion Foundation
Transactional Services
These services handle user-initiated commerce transactions requiring consistent state management and rollback capabilities.
Cart User Authorization List Orders Subscriptions Loyalty
Inbuilt Apps
Platform-provided inbuilt applications handling cross-cutting commerce capabilities. These are bundled with the platform and consumed by both storefront and transactional microservices.
Payment Search Shipping Tax Address Notification
Section 6
ACTION API Pattern
Replacing the Orchestration Layer
In previous versions of Equinox, a dedicated Orchestration Layer (Apache Camel) aggregated data from multiple microservices into a single response for the Presentation Layer. In 9.x, this responsibility moves inside each microservice via the ACTION API pattern. This eliminates an entire network tier, reduces latency, and simplifies the deployment model.What is an ACTION API?
An ACTION API is a capability endpoint exposed by a microservice that goes beyond simple CRUD operations. It serves as a central place for customer-specific business logic and an integration point for third-party or client’s in-house microservices. ACTION APIs:
Aggregate internally
Calls to sibling domains (e.g., Catalog fetching Price data for a product details response) are resolved within the microservice boundary rather than at a separate orchestration tier.
Ties services together
NodeJS-Fastify based ACTION APIs tie various downstream services together. They serve as the central point for business logic composition, replacing Apache Camel routes.
Single API Surface
The Presentation Layer calls a single ACTION API endpoint per page or operation. The microservice returns an aggregated, ready-to-render response without requiring additional hops.
Plugin Integration Point
ACTION APIs are the extension point for plugins. Third-party or client plugins can intercept, augment, or replace ACTION API behavior through the Plugin SDK without forking platform code.
Product Details Page (PDP) — ACTION API Illustration
As an example, in the previous architecture a Storefront Orchestration service would call Catalog, Price, Promotion, and Merchandising services, then assemble the response. In 9.x, a single Catalog microservice ACTION API call returns the aggregated PDP response:
PDP — ACTION API Sequence Diagram (Equinox 9.x) Storefront Presentation Layer (React App) PIM Service PDP ACTION API · Catalog · Categories · Price (Product Information Management — IS the Catalog Service) Promotion Service Promotions · Deals · Coupons (Promo Engine) Inventory Service Stock · Availability · Location (Availability Check) GET /pim/action/pdp/{sku} Internal Resolution (within PIM) ▸ Catalog Info (product attributes, SKU) ▸ Category Details (hierarchy, breadcrumbs) ▸ Regular & Sale Price (list + sale) All resolved internally — no external call needed for these data domains par PIM calls Promotion & Inventory in parallel after internal resolution Get Promotion Details for SKU Check Inventory Availability for SKU Applicable Promotions & Deals Data Inventory Availability Status (In Stock / OOS) PIM aggregates: Catalog + Price + Promotions + Inventory Aggregated PDP Response (Catalog + Categories + Price + Promotions + Inventory) Storefront PIM Service Promotion Service Inventory Service Sync call / responseExternal parallel callPIM internal (Catalog+Category+Price)PromotionInventory
Note: The PIM Service is the Catalog Service in Equinox 9.x. The Storefront calls the PIM PDP ACTION API directly. PIM resolves Catalog Info, Categories, and Price internally (no external call needed for these). It then fans out two parallel calls — to Promotion Service for applicable deals, and to Inventory Service for real-time stock availability — aggregates all responses, and returns a single composed PDP payload to the Storefront.
Rendered PDP Page — Annotated Data Sources (Equinox 9.x)
Section 7
Persistence Layer
The Persistence Layer is where data created by business administrators and storefront users is stored and retrieved. Infosys Equinox 9.x adopts a Document-first (NoSQL) strategy across the platform, simplifying the data tier and removing the relational database requirement for most services.
🍃
MongoDB — Primary Datastore
- Document-based NoSQL database for both transactional and non-transactional data
- Replaces the dual MySQL + MongoDB store of prior versions
- Flexible schema accommodates the diverse data shapes of commerce microservices
- Spring Data MongoDB abstraction removed in 9.x (native NodeJS MongoDB driver)
- Each microservice owns its own MongoDB database — no shared schemas
Primary Store
⚡
Redis — In-Memory Cache
- Stores and fetches frequently used data rather than hitting MongoDB on every request
- Session management and short-lived token storage
- Rate limiting and distributed locks across microservice instances
- Cache invalidation triggered by microservice domain events
Caching Layer
🔍
Amazon OpenSearch Service — Search Engine
- Replaces Apache SOLR as the platform’s search and faceting engine in 9.x
- AWS-managed OpenSearch (Elasticsearch-compatible) — fully serverless, highly available
- Provides full-text search, faceted browse, autocomplete, and relevance tuning
- Index updates triggered by microservice domain events on data change
- Powers storefront search, category browse, and filtering capabilities
- Natively integrates with AWS IAM, VPC, and CloudWatch for security and observability
Search & Faceting
Removed from 9.x
MySQL (SQL datastore), Apache SOLR (search indexing via Pentaho jobs), and Apache JackRabbit (JCR) (content repository) are no longer part of the 9.x platform stack. Asset management and binary content are handled via cloud-native object storage services.Section 8
Previous Platform vs Equinox 9.x — Key Changes
The following table summarizes the primary architectural and technology changes introduced in version 9.x relative to the prior platform version.
| Dimension | Previous Version | Equinox 9.x |
|---|---|---|
| Architecture Layers | 4 layers: Presentation → Orchestration → Microservices → Persistence | 3 layers: Presentation → Microservices (with ACTION APIs) → Persistence Changed |
| Orchestration | Dedicated Orchestration Layer — Apache Camel + Spring Boot. Admin Orchestration + Storefront Orchestration modules. | Removed. ACTION APIs within each microservice handle aggregation internally. Removed |
| Microservices Runtime | Java — Spring Boot. Plugin-based extension model. | NodeJS — Fastify framework. Plugin-based extension model retained. Changed |
| Admin Portal | Spring Boot + Thymeleaf + MD Bootstrap. Each business tool independently bootable. | React-based micro front-end. Each tool independently bootable. Changed |
| SQL Datastore | MySQL with Hibernate + Spring Data JPA | Removed — MongoDB (NoSQL) covers all use cases. Removed |
| NoSQL Datastore | MongoDB + Spring Data MongoDB | MongoDB — native NodeJS driver (no Spring abstraction). Primary and only datastore. Updated |
| Search Engine | Apache SOLR — indexed via Pentaho ETL jobs | Amazon OpenSearch Service (AWS) — managed Elasticsearch-compatible engine, event-driven index updates, AWS-native integration. Replaced |
| Cache | Redis | Redis — unchanged. Same |
| Content Repository | Apache JackRabbit (JCR) for assets | Removed — cloud-native object storage (S3-compatible). Removed |
| Storefront | React + NodeJS, B2C and B2B storefronts | React + NodeJS, B2C / B2B / B2B2C storefronts. Calls ACTION APIs directly. Updated |
| Inter-Service Comm. | Asynchronous events only (no REST between microservices). Orchestration handled by Camel layer. | Asynchronous events + ACTION API internal calls within a microservice boundary. Enhanced |
| Plugin Extension | Plugin-based extension model; Java plugins deployed alongside Spring Boot microservices. | Plugin SDK for NodeJS; plugins deployed as Fastify plugins or companion microservices. Updated |
Section 9
Technology Stack Summary
Runtime & Frameworks
Microservices Runtime NodeJS Core
HTTP Framework Fastify Core
Storefront / Admin UI React (NodeJS) Core
API Style REST (CRUD + ACTION APIs) Core
Inter-service Events Async Event Bus (no synchronous REST between MS) Core
Data & Infrastructure
Primary Database MongoDB (NoSQL / Document) Persistence
Cache Redis Persistence
Search & Faceting Amazon OpenSearch Service (AWS Elasticsearch) Persistence
Deployment Target AWS / Azure / GCP / On-Premise Infra
Architecture Pattern MACH-X (Microservices, API-first, Cloud-native, Headless) Pattern