TECH SUMMARY | High Level Platform Architecture

1. High-Level Architecture

The Personalisation Hub Platform follows a micro-services architecture. It is designed to be a distributed system with a modular and scalable structure.

The high-level architecture can be visualised through the following diagram:

1.1. Primary Platform Components

The above diagram illustrates the main components of the Platform, these are summarised below:

Auth Api: used to authenticate Platform users & manage user roles/permissions.

Campaign Mobile & Campaign Api: manages access to the Platform’s Campaign Repository. Campaigns can be localised and personalised by Store, by Display and/or by Visitor.

Retail Admin: allow Store Staff/Managers to view and where approved update Retail Data as well as control Localised Campaign Playback at an individual Retail Store level. When enabled, this interface also provides Retail/Branch Staff with access to manage their respective Store’s Queue/Appointments.

HQ Admin: allow Headquarters to manage and deliver Localised and Personalised/Targeted Campaigns across all connected Stores/Displays/Campaign-Sites/Store-Tablets. The Platform provides an Orchestration Layer that allows Enterprise Clients to seamlessly manage Retail Hardware (Displays, Devices & IoT), Experience Software/CMS (Adobe Experience Manager, Dialogflow/Chatbots, etc); Other 3rd Party Integrations (CDP/CRM Data, 1st Party Data, Decisioning Data, etc) as well as Seamless Visitor/Customer Identification in Retail/Branches (Check-Ins, Queueing, Appointments, Click&Collect, etc).

Store Queuing: allows Visitors/Customers to instantly join a Queue when they require Assistance. Retail/Branch Interactions (& any Integrated Customer Data is seamlessly surfaced to Retail Staff).

JCR: integration layer between the Personalisation Hub Platform and Adobe Experience Manager (AEM). used to call AEM’s Java Content Repository (JCR) API.

Location API: serves all localised data used to Refine Campaign Targeting across our client’s Retail/Branch network. ‘Location API’ also hosts the ‘Visitor API’ that gets used to match connected Visitor/Customer Data to the Retail-Store/Branch's respective Displays/Devices.

MIST: allows clients to support Proximity based Targeting within their Retail-Stores/Branches.

Background Task: Daemon service, run background jobs or scheduler.

Monitoring Tools: leveraging a number of monitoring tools (i.e. prometheus, grafana), we are able to support proactive issue detection, service reliability and ensure ongoing performance optimisation.

Location Toolkit: Receive Campaign Playback data from AEM/Displays to ensure accurate view of exactly which Campaigns are Playing on what Displays. Also provides immediate warnings when Playback issues are detected on a specific Display. Campaign Playback data can be used to report on a respective Campaign’s Performance to Brands/Advertisers.

Squid proxy: proxy used to communicate with external parties.

Adobe Experience Manager: server for dealing with AEM content/interactions.

1.2. AWS Services Utilised

Below is a summary of the various AWS features/services that are used by the Platform:

EKS service - Manage Kubernetes clusters/services to ensure availability and scalability.

RDS service: We use RDS to setup, operate the PostgreSQL databases. 

S3 service: We use S3 service to store Platform data.

KMS service: Key Management Service is used to securely store/encrypt data.

Elasticache for Redis service: Redis is used to optimise platform performance.

MSK service: (aka Kafka) ensures that the Platform can support high-volume, real-time data streams, scalable and fault-tolerant.

SNS service: used to support Email or SMS/Text messaging.

Elasticsearch Service service: (aka AWS OpenSearch). allows Platform to support a scalable search solution for platform logging and monitoring.

2. Rationale

The chosen architectural style was selected to meet the functional requirements and provide the following benefits:

Simplify Kubernetes Management: abstracts away the complexity of managing Kubernetes clusters, allowing operators to focus on deploying and running applications rather than dealing with the underlying infrastructure.

Scalability and High Availability: It automatically handles the provisioning and scaling of worker nodes / pods based on application demand, ensuring that the Platform can handle increased traffic and workload.

Integration with AWS Services: EKS seamlessly integrates with various AWS services, such as Amazon EC2, Elastic Load Balancing, Amazon RDS, Amazon S3, and more. This integration simplifies the deployment and management of applications that require interaction with other AWS services, allowing us to leverage the full capabilities of the AWS ecosystem.

Security and Compliance: EKS provides built-in security features to help protect applications and data. It integrates with AWS Identity and Access Management (IAM) for fine-grained access control, supports network isolation through Amazon VPC, and offers encryption at rest and in transit. EKS also helps us meet compliance requirements by providing features like audit logging and integration with AWS CloudTrail.

Flexibility and Portability: EKS is compatible with standard Kubernetes APIs, allowing us to use existing Kubernetes tools, libraries, and configurations. This compatibility ensures application portability, enabling us to migrate Kubernetes workloads easily between different environments.

Continuous Deployment and Automation: facilitating continuous integration and deployment (CI/CD) workflows. We can automate the deployment of containerised applications, ensuring faster release cycles and reducing manual intervention.

Cost Optimisation: EKS offers cost optimisation features, such as automatic scaling of worker nodes / pods based on demand, which helps to optimise resource utilisation and minimise costs.

These are the reason why we selected to use Kubernetes when building the Personalisation Hub Platform.