Skip to main content

Architecture

System context​

System context

Containers​

Containers

Architecture decision records​

  • ADR-0001 - Record architecture decisions
  • ADR-0002 - gRPC
  • ADR-0003 - Use Java 21 Loom for multithreading
  • ADR-0004 - Follow API-First practices
  • ADR-0005 - Use Cloud Run
  • ADR-0006 - Use CCC Configuration Portal for customer configuration
  • ADR-0007 - Use bidirectional event streams with the Checkout App
  • ADR-0008 - Use Service Manager
  • ADR-0009 - Use Device Router

APIs​

The following APIs are part of cashchangers:

TO BE CREATED

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 proto3 interface.

The API for receiving responses is a proto3 interface.

Deployability​

We will deploy in three environments: cloud, edge and local. For deployment, we will use:

  • for the cloud: Cloud Run.
  • for the edge: Avassa.
  • for local: Service-Manager.

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.

Consistency over availability​

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.

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.

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.