Skip to content

Architecture overview

SISS is a service-per-domain microservices system: eight services behind a single API gateway, with Temporal as the durable orchestrator for long-running workflows and Pub/Sub as the event backbone for cross-service integration.

High-level shape

flowchart TB
  SPA[React SPA<br/>PSP portal · Officer console · xeokit BIM viewer]

  GW[API Gateway<br/>Cloud LB · Cloud Armor · IAP]

  subgraph Services["Microservices"]
    direction LR
    CORE[core-svc]
    SUB[submission-svc]
    WF[workflow-svc]
    CMT[comment-svc]
    AI[ai-svc]
    BIM[bim-svc]
    SIGN[signing-svc]
    NOT[notification-svc]
  end

  BUS((Pub/Sub<br/>event bus))

  subgraph Data["Shared infrastructure"]
    direction LR
    DB[(AlloyDB<br/>per service)]
    GCS[(GCS buckets)]
    VTX[Vertex AI<br/>+ Vector Search]
    TMP[Temporal]
    KMS[Cloud KMS]
    BQ[(BigQuery<br/>audit)]
  end

  SPA --> GW --> Services
  Services <--> BUS
  Services --> Data
  BUS --> BQ

Eight services

Service Owns
core-svc Identity broker (wraps GCP Identity Platform), RBAC policy store, org / tenant, audit stream
submission-svc Submission aggregate — metadata, pre-consultation checklist, file index, revisions, status, dashboard reads
workflow-svc Temporal workflow definitions and activity routing
comment-svc Inline markup, structured comment templates, comment library, response tracker, revision comparison
ai-svc Document extraction, compliance checking, comment drafting, risk-area highlighting, revision diff summarisation
bim-svc IFC validation, metadata extraction, XKT tile generation, zoning envelope comparison
signing-svc PAdES digital signatures via Cloud KMS for Kertas Perakuan, SIGL, Surat Sokongan
notification-svc Email, SMS, and in-app notifications driven by domain events

Why microservices

The milestone structure forces parallel delivery tracks with distinct runtime profiles: transactional CRUD, long-running AI pipelines, heavy BIM processing, cryptographic signing. Separate services let each track —

  • scale independently (BIM workers on GPU node pools vs. thin CRUD services on Autopilot),
  • deploy independently per milestone without coordinated releases,
  • be owned by separate sub-teams as the project grows,
  • isolate the signing service, which has the tightest compliance surface.

The cost is operational complexity; it is absorbed by leaning on managed GKE Autopilot, managed Pub/Sub, and managed AlloyDB.

  • Technology stack — the locked choices per layer.
  • Services — per-service detail.
  • Data — storage layers, IDs, and the submission aggregate ERD.
  • Events — the Pub/Sub catalog and one submission's event trail.
  • Workflows — Temporal, and the end-to-end KM submission workflow.