Inventory & Finance Management SaaS — Sequential End-to-End Flow Simulator

One client at a time. Each scenario follows the real request path from client ingress to the final processing layer. Protocol transformation is shown only where it is actually required.
Ready
CLIENTS — SELECT ONE CLIENT AND FOLLOW ITS FLOW END-TO-END Web Browser / MFEsgRPC-Web • HTTPS • browserCan use HTTP/1.1 or HTTP/2 iOS AppNative gRPC • HTTP/2No gRPC-Web conversion Android AppNative gRPC • HTTP/2No gRPC-Web conversion Desktop / POSNative gRPC • HTTP/2Immediate business response 3rd-Party / API ClientREST/JSON • HTTP/1.1 or HTTP/2API key / OAuth credentials Marketplace / WebhookREST / HTTPS webhookShopify / Amazon / WooCommerce GATEWAY — ONLY THE REQUIRED PROTOCOL HANDLING IS SHOWN gRPC-Web HandlerInput: gRPC-Web over HTTP/1.1 or HTTP/2Action: translate gRPC-Web → native gRPCInternal transport: gRPC / HTTP/2Only used by browser-based clients Native gRPC HandlerInput: native gRPC / HTTP/2Action: no protocol conversionValidate metadata + forwardUsed by native mobile/desktop clients REST HandlerInput: REST/JSON over HTTP/1.1 or HTTP/2Action: validate JSON + API versionAdapt REST/JSON → internal gRPCInternal transport: gRPC / HTTP/2 Auth / Tenant ContextOpaque token / API credential→ Identity & Organization service→ Keycloak validation→ trusted userId + tenantId + scopes Routing / ReliabilityGateway → target Service Load Balancertimeouts • retry policy • rate limittrace ID • request ID • CORSNo business logic SERVICE LAYER — EVERY SERVICE IS BEHIND ITS OWN LOAD BALANCER Identity & Organization LB→ 2 service instancesUsers • roles • tenant membershipKeycloak integration Product & Inventory LB→ 3 service instancesProduct • stock • reservationWarehouse • movements Sales & Order LB→ 3 service instancesCanonical sales/orderOutbox → Kafka Finance & Accounting LB→ 2 service instancesLedger • journals • AR/APFinancial source of truth Integration LB→ 3 service instancesWebhooks • external syncExternal → canonical mapping Platform Communication LB→ 2 service instancesEmail • SMS • pushAsync event consumers Sync rule: Service A never calls Service B instance directly. It calls Service B's Load Balancer, which selects a healthy instance. Critical transaction examples: Sales → Product & Inventory (reserve stock); Integration → Sales (canonicalize marketplace order). PERSISTENCE + EVENTING PostgreSQL — transactional source of truthEach bounded context owns its dataSales uses Outbox for DB + event reliability RedisHot product/inventory cacheNot a source of truth Apache Kafka — asynchronous eventssales.events • inventory.events • finance.eventscatalog/tenant • integration • notification eventsConsumer groups • idempotency • retry/DLQ CassandraIntegration/event historyDenormalized read models Object StorageInvoices • imagesImport/export files FINAL / DOWNSTREAM PROCESSING Reporting / Analytics Read ModelConsumes events → dashboards and reportsEventually consistent by design External Sync / Partner EffectsOutbound marketplace APIs/webhooksIntegration-driven side effects Email / SMS / Push ProvidersFinal notification deliveryFailure isolated from core sale Audit / ObservabilityLogs • metrics • tracesAudit trail Final Response / CompletionResponse returns through Gatewayor async processing completes