Copy page

Documentation

Architecture

This page summarizes the platform topology represented in the current Alpha Looms architecture diagram.

The diagram shows the end-to-end runtime boundary, from public entry and identity enforcement through to internal downstream services, managed data stores, and GitOps-based deployment.

Use the diagram as a reference map for platform boundaries, traffic direction, and service placement. It is most useful when read together with the gateway, service, and data explanations below.

Platform Boundary

Alpha Looms runs inside an Azure Private VNet with an AKS Cluster deployed inside the network boundary. Within that cluster, the platform is segmented into ingress, gateway, platform-service, downstream-service, and data-integration zones.

The diagram shows two important exposure patterns:

• public traffic entering through the public edge
• service-to-service communication inside the cluster through Kubernetes DNS and services

Public Entry Path

The public path shown in the diagram is:

1. Admin Web, Borrower Web, Sales Web, or Sales App
2. DNS
3. Public Loadbalancer
4. NGINX Ingress Controller
5. target gateway or platform service

This path is used for borrower-facing and internal operational experiences that must be available through the public edge.

Internal Service Communication

Inside the cluster, services communicate with each other through Kubernetes DNS and service discovery.

This internal path is used for downstream-to-downstream communication rather than a separate internal load-balancer entry pattern.

Gateways And Identity

The access layer includes:

• Admin API Gateway
• Borrower API Gateway
• OpenAPI API Gateway
• Keycloak

The gateways sit behind ingress and coordinate token validation through Keycloak. This separates user and client entry concerns from downstream business-service execution.

Platform Services Around The Edge

The diagram shows several supporting services connected near the ingress and gateway layer.

• Formio for form-centric flows
• N8N for workflow automation and integration logic
• Supabase for shared platform capabilities
• Superset for analytics and reporting use cases

These services are not all equivalent from an integration point of view, but they form an important part of the platform runtime shown in the architecture.

Downstream Service Zone

Inside the downstream services boundary, the architecture groups multiple business and operational services.

Rather than listing every microservice individually, read this area as the runtime home for lending, workflow, document, analytics-supporting, and other domain downstreams.

Where useful, the diagram also calls out a few distinctive services such as Auth, Log management, and beta-related components.

Data And Infrastructure Dependencies

The services in the cluster depend on several managed data and messaging systems shown outside the downstream-service zone.

Data Stores

• MongoDB
• MySQL Flexible Servers
• PostgreSQL Flexible Servers
• Redis

Storage And Messaging

• storage accounts including betateststorage and authalphatest01
• Service Bus

These dependencies indicate that the platform uses different persistence technologies depending on service needs rather than forcing all domains into a single storage model.

Delivery Flow

The delivery path represented in the diagram is:

1. Developer produces a new version
2. code is pushed through GitHub
3. ArgoCD synchronizes the desired state
4. workloads are updated in the AKS environment

This makes the deployment workflow part of the documented platform architecture rather than an operational detail hidden outside the docs.

How To Use This Page

• Use this page to understand where a service sits in the overall platform
• Use Access And Authentication for the entry and identity path
• Use Services And Data for a service-to-dependency view
• Use the API Catalog when you need contract-level integration details