Skip to main content

Architecture

System context​

System context

Containers​

Containers

Architecture decision records​

APIs​

The following APIs are part of cashchangers:

IDEALS​

Hii Retail services adheres to the IDEALS principles in microservice architecture. This section covers how the design choices in cashchangers fulfills the IDEALS.

Interface segregation​

The API for sending requests is a REST interface that supports sending application/json.

The API for polling responses to sent requests will return application/json.

Events are delivered as JSON via Pub/Sub, but can potentially also be polled from the outbox service if such a scenario emerge.

Deployability​

The services in the solution are designed to be independently releasable and uses schema-based communication internally via gRPC.

Event-driven​

All services are designed as being event-driven, where requests and/or events trigger flows that eventually triggers RPC-calls. The services require no CPU cycles outside the request context -- save the maintenance of keeping streams up.

Availability over consistency​

The system is designed to be an extension to the hardware in store. The actual hardware maintains state, as well as the in-store application. For optimizations, we aim to maintain a smaller state for hardware to be more responsive during temporary outages etc.

Loose-coupling​

This set of services does not rely on any other than the Checkout Engine, as a consumer of our APIs.

Single responsibility​

Each of the services within the suite is purposefully built to fulfill its requirement;

  • Connector processes requests and models responses of the data received from the stores and acts as a message broker for the request/response and events flowing between the cloud and stores.
  • The response outbox stores and retrieves responses and exists to support on-prem solutions.

General considerations​

The outbox exists to support on-prem solutions, and is the service we will support. If there should be a future demand for other means of deliveries, the system is able to support multiple communication paths.

Multi-tenancy​

The suite of services is fully multi-tenant.

Auditing​

There is no current need to implement auditing.

Security​

  • All ingress and egress uses TLS
  • All APIs are secured using either
    • Hii Retail IAM (for users)
    • Workload identity
    • OCMS

Redis is namespaced by service, so that each service has its own queues/maps.

Each response in the outbox prefixes each entry by tenant-id in addition to namespace.

The service will not use any directly identifying personal data.

Data mesh​

Not in scope.

Global reach​

Redis is a component we have that we cannot scale beyond regions.

Internationalization​

Responses and events will need translation support. When the implementation is needed we will investigate the most appropriate approach, also taking into consideration any possible translation service.