Skip to content

AWS 2026-10-14

Read original ↗

How UTS established a modern curriculum data services foundation on AWS

Summary

The University of Technology Sydney (UTS) IT Unit built its first production governed data domain — curriculum — on AWS, applying domain-driven design to expose authoritative curriculum information as reusable services without displacing the third-party SaaS Curriculum Management System (CMS) as the system of record. The architecture captures every CMS change as an event, preserves it on a durable append-only log (Amazon MSK Serverless), materialises purpose-built read projections (a property graph in Amazon Neptune Serverless and documents + vector/full-text indices in Amazon OpenSearch Service), and serves them through governed REST / GraphQL / event interfaces. Both stores are disposable, independently and eventually consistent projections that can be rebuilt by a full domain reload from the CMS — never competing systems of record. The result since the November 2024 production launch: zero production incidents, 1.6 s average end-to-end latency, 43,794 modelled relationships, 11 institutional consumers, and one engineer operating the whole domain.

Key takeaways

  • Domain-driven design with a hard bounded context. Data services are aligned to the curriculum domain, not to the applications that produce or consume data. The CMS stays the system of record; validation, ownership and governance are deliberately kept from migrating into the non-authoritative data services. Institutional data is treated as a governed data product with explicit ownership, consumers, quality expectations, interface contracts and lifecycle. (Source: article)
  • Five-layer architecture — edge, ingestion, persistence, application/business logic, interface — with identity, encryption, network controls, observability and operational governance spanning all layers.
  • Edge is a thin technical adapter, validation stays in the source. The CMS posts proprietary change events to API Gateway (HTTP API) → a Lambda technical adapter wraps the whole vendor event in a CloudEvent envelope, appends UTS operational metadata, and publishes to the appropriate MSK Serverless topic. The edge performs no validation or consumer-specific transformation, preserving source fidelity and letting the stateless edge auto-scale during complete domain reloads.
  • MSK Serverless is the durable append-only event backbone. Changes are segregated into domain-aligned topics by academic item type; independent consumers progress, retry and recover without blocking one another. It scales on demand — routine changes consume little capacity; a full domain reload fans out across the backbone and parallel processors, then contracts. Model/schema changes are absorbed by idempotent reprocessing or a complete reload without introducing a second curriculum authority.
  • Purpose-built persistence selected by access pattern. Amazon Neptune Serverless stores curriculum structures and inverse relationships as a property graph (programmes ⇄ areas ⇄ units); inverse enquiries ("every programme a unit is taught through") are native graph traversals rather than application-reconstructed joins. OpenSearch stores complete source documents plus indices for exact, full-text, and k-NN vector retrieval; selected Lambda processors call an embedding model via Amazon Bedrock and append vectors before persistence, enabling semantic discovery (validated for multilingual retrieval against English content).
  • Projections are disposable, never systems of record. Neptune and OpenSearch are independently and eventually consistent; failure of one materialisation doesn't block another; neither is exposed directly to consumers; both are rebuildable from the CMS via a complete reload. This is the textbook async-projected read model / event-sourcing-plus-projections shape.
  • Applications layer = dozens of narrow Lambda-backed domain services. They query Neptune or OpenSearch while persistence stays private, exposed only through governed contracts. EventBridge Pipes are transport adapters between MSK and the Lambda processors/services (routing/delivery only, no validation/enrichment/business transformation). SigV4 + fine-grained IAM give least-privilege access to Neptune/OpenSearch with no distributed DB credentials.
  • Interface layer offers pull + push without exposing storage. API Gateway supplies REST; AWS AppSync supplies GraphQL with attribute-based access control at schema level; both invoke the same governed service contracts. EventBridge Pipes handle last-mile delivery of CloudEvent-enveloped domain events, and consumers choose which academic-item events are relevant (no per-consumer filtered stream to maintain). Amazon Cognito authenticates external consumers via OAuth 2.0 / OIDC; AWS-native workloads use IAM.
  • Governed data contracts replace point-to-point integrations. 11 institutional consumers replaced bespoke consumer-specific interfaces with reusable governed contracts that insulate them from source schemas and implementation detail — the data-contract pattern applied to an internal data domain.
  • Operated by one engineer with zero incidents. Managed, serverless, self-healing components removed the need for dedicated Level-3 support; consumption-based pricing aligned spend with intermittent-peak workload instead of permanently-provisioned capacity. The platform has served trusted curriculum data even while the upstream CMS (system of record) was unavailable.

Operational numbers

  • Avg. end-to-end latency: 1.6 s from crossing the edge to availability on synchronous and asynchronous interfaces.
  • Curriculum graph: 43,794 relationships across ≈ 800 programmes of learning, 3,500 units of learning, 2,500 areas of learning.
  • Consumers: 11 institutional consumers adopted the governed services.
  • Operational footprint: one engineer; no dedicated L3 support.
  • Incidents: zero production incidents since the November 2024 launch.

Systems / concepts / patterns extracted

Caveats

  • Reference/customer-success framing. This is an AWS Architecture Blog partnership post about a UTS build; it reads as an architectural + operating-model success story. The headline numbers (1.6 s latency, zero incidents, one engineer) are UTS-reported and not independently benchmarked, and no percentiles, throughput, topic/partition counts, Neptune/OpenSearch sizing, or cost figures are disclosed.
  • No internals of the managed services (MSK broker topology, Neptune/OpenSearch node sizing, EventBridge Pipes throughput) are given — the post describes how UTS uses them, not their internals.
  • "Average" latency only — the 1.6 s figure is an average across sync and async paths; tail behaviour is not reported.
  • Multilingual retrieval "validated", not quantified — the semantic cross-language capability was validated against English-language curriculum, with no recall/precision numbers.

Source

Last updated · 854 distilled / 2,448 read