Skip to content

Deployment

Target Architecture — Final-State Design

This page describes the final-state deployment of the Marketplace Platform. Services and workers run as containers on Azure (AKS/Container Apps); infrastructure is provisioned with Pulumi (infrastructure-as-code) and delivered through the factory's GitOps pipelines. Messaging is Azure Service Bus; data is Azure SQL / PostgreSQL, Azure Blob, Azure Artifacts, and the Azure Container Registry.

The eleven microservices and five workers deploy independently, scale to their own load profile, and share the factory's platform services (authorization server, API gateway, Key Vault, observability backend).

Runtime model

  • Containers on Azure — each service .Api and each worker is a container image in the Azure Container Registry, deployed to AKS (or Azure Container Apps) as an independently versioned unit.
  • API gateway — public APIs are fronted by the factory ApiGatewayTemplate gateway, which terminates TLS, validates tokens, and routes to services.
  • Service mesh — inter-service traffic uses mTLS workload identity; internal APIs and gRPC are mesh-internal only.
  • Messaging — MassTransit consumers connect to Azure Service Bus topics/subscriptions per Events.
  • Stateless services, externalized state — services hold no local state; all state is in Azure SQL/PostgreSQL, Blob, Artifacts, ACR, and Redis (see Storage).

Deployment topology

flowchart TB
    subgraph Edge["Edge"]
        GW["API Gateway"]
    end
    subgraph Cluster["AKS / Container Apps"]
        subgraph Services["Marketplace Services"]
            MCS["MarketplaceCatalogService"]
            MSS["MarketplaceSearchService"]
            APS["AssetPublishingService"]
            AVS["AssetVersionService"]
            ACS["AssetCompatibilityService"]
            DRS["DependencyResolutionService"]
            AIS["AssetInstallationService"]
            LS["LicenseService"]
            PS["PricingService"]
            PPS["PublisherPortalService"]
            RRS["ReviewRatingService"]
        end
        subgraph Workers["Workers (KEDA-scaled)"]
            MPW["MarketplacePublishingWorker"]
            QSW["AssetQualityScanWorker"]
            IDX["AssetIndexingWorker"]
            CEW["CompatibilityEvaluationWorker"]
            IW["InstallationWorker"]
        end
    end
    subgraph Platform["Shared Platform"]
        Bus["Azure Service Bus"]
        SQL["Azure SQL / PostgreSQL"]
        Blob["Azure Blob"]
        Art["Azure Artifacts"]
        ACR["Azure Container Registry"]
        Redis["Redis"]
        Search["Search index"]
        KV["Azure Key Vault"]
        OTel["Observability backend"]
    end

    GW --> MCS
    GW --> MSS
    GW --> APS
    GW --> AIS
    GW --> ACS
    Services --> SQL
    Services --> Redis
    MSS --> Search
    AVS --> Blob
    AVS --> Art
    AVS --> ACR
    Services --> Bus
    Workers --> Bus
    Workers --> SQL
    Services --> KV
    Services --> OTel
    Workers --> OTel
Hold "Alt" / "Option" to enable pan & zoom

Scaling

  • Services scale horizontally on CPU/RPS; read-heavy MarketplaceCatalogService and MarketplaceSearchService scale most aggressively and lean on Redis and the search index.
  • Workers scale on Azure Service Bus queue depth via KEDA; AssetIndexingWorker, CompatibilityEvaluationWorker, and InstallationWorker scale to absorb bursts (e.g. mass re-index after a catalog change).
  • Stores scale via Azure SQL/PostgreSQL tiers and read replicas for catalog reads; Blob/Artifacts/ACR scale natively.
  • Multi-region (final state) — catalog/search read replicas and geo-redundant package stores serve nearest-region reads; writes home to the primary region.

Configuration

  • Options pattern — each service/worker is configured through strongly typed Options bound from environment/config, with secrets injected from Key Vault.
  • Per-environment — development, staging, and production configurations are managed as Pulumi stacks; no environment-specific values are baked into images.
  • Feature gating — catalog visibility, trust-tier auto-approval thresholds, and pricing-model availability are configuration-driven.

Secrets

  • All secrets (DB credentials, Service Bus connection, signing keys, billing integration, store credentials) live in Azure Key Vault, retrieved at runtime via managed identity. Nothing secret is in images, config files, logs, or API responses (see Security).

Health and readiness

  • Each service exposes /health/live and /health/ready (via HealthChecksAggregatorTemplate) covering database, Service Bus, cache, and dependent-store connectivity.
  • Workers report consumer health and Service Bus connectivity; readiness gates rolling deploys.
  • A platform health aggregator rolls up service/worker health for the Control Plane and Observability dashboards.

Delivery (IaC + GitOps)

  • Pulumi defines all infrastructure (clusters, Service Bus namespaces/topics, SQL/PostgreSQL, storage, Key Vault, ACR/Artifacts feeds, search).
  • The factory's GitOps pipelines build images, run migrations (DatabaseModel.Migrations), and roll out services/workers with health-gated, progressive deployment and automated rollback on failed readiness.

Continue to Storage, Observability, and Extension Roadmap.