Architecture

Architecture

My-Scan follows a hub-and-spoke architecture centered on the Core Service, which owns the basket/ticket lifecycle and exposes all client-facing APIs. The Core Service delegates specialized concerns to dedicated backend services and external systems: it calls the ItemData Service to resolve scanned barcodes into item, price, and promotion data; it delegates checkout execution to a configurable Checkout Engine; it publishes basket and assistance events to the Attendant / Hii Retail PubSub integration; and it coordinates with the loss-prevention ecosystem whenever a post-checkout rescan or audit is required.

My-Scan is designed to run in two host environments:

• Cloud - multi-tenant, deployed to Google Cloud, uses Redis for basket state, HiiRetail Attendant/PubSub for monitoring, and OCMS/workload identity for authentication.
• OnPrem - single-tenant, deployed at the retailer's side, integrates directly with in-store business servers, uses in-memory or local state, and disables cloud-only features.

For how these components connect to external systems, see Integrations.

Components

Component	Role
Core Service (Mdc.MyScan.Core.Service)	ASP.NET Core Web API. Entry point for all Shopper, POS, Administration, and Internal API traffic; authentication, routing, and request/response logging.
Core Service Logic (Mdc.MyScan.Core.Service.Logic)	Command/handler layer implementing basket business rules - start, add/remove item, quantity updates, finish, cancel, abandoned-trip cleanup.
Core Common (Mdc.MyScan.Core.Common)	Shared DTOs, API group definitions, topic names, pincode handling, and cross-cutting utilities.
Selfscan (Mdc.MyScan.Core.Selfscan)	Domain/business-logic implementing the in-store self-scanning shopping journey, orchestrating calls to external price engines and customer services
Checkout (Mdc.MyScan.Core.Checkout)	Checkout orchestration: control determination, payment processing, ticket download/upload (POS API), and attendant push handling.
ItemData Service	Resolves scanned barcodes to item, price, and promotion data for on-prem.
Basket Audit Determination Service	Post-checkout rescan verification: determining when a rescan is required (for the Cloud environment).
Basket Audit Service	Post-checkout rescan verification: running a rescan session (for the Cloud environment).
Attendant / Hii Retail PubSub	Publishes basket monitoring events and handles assistance/control-resolution events.
Redis	Backing store for basket/ticket state in the Cloud host environment.

Event Flow

My-Scan combines synchronous request/response APIs with asynchronous event publishing for cross-service coordination:

Basket lifecycle events - On basket transition the Core Service publishes a BasketUpdated event (mys.public.event.basket-updated.v1) via the Attendant/PubSub integration, tagged with a BasketStatus.

Assistance requests - When a shopper requests help (assistanceRequested on Finish), an event is sent to the Attendant service, the result is later delivered back asynchronously.

Rescan / basket audit - When a basket is selected for rescan, the loss-prevention ecosystem reports completion or stop back to the Core Service via BasketAuditPushController.

Analytics - After a ticket is uploaded (POS API), transaction data is forwarded to the Self-Service Analytics (SSA) service as a POS transaction event.

Authentication Flow

All service-to-service and client-to-service calls in the cloud environment follow a consistent token-based model:

1. Inbound requests (Shopper/POS/Administration APIs) must include an Authorization: Bearer <token> header - a token issued via OCMS or workload identity - along with a Tenant-Id header. Tenant-Id is required for all cloud requests and is resolved from the token claims or, if absent, from configured OCMS settings.
2. Outbound requests are authenticated the same way: a workload identity authenticator fetches a scoped token for the target audience, the token is attached as Authorization: Bearer <token>, and Tenant-Id is propagated from the originating request context.