Federico Rao
ELMS LEARN
A learning platform case study focused on enterprise architecture, education workflows, scalable interfaces, and AI-assisted learning experiences.
System shape
Fourteen independently deployable Spring Boot services sit behind an API gateway, each owning its own PostgreSQL database so that bounded contexts are enforced by deployment rather than by convention. Services communicate through REST clients for synchronous calls and Kafka event streaming for asynchronous workflows such as enrolment, progress tracking, and notification fan-out. The React frontend spans four distinct user roles with route-level code splitting and a development pattern that falls back to mock data when a service is unavailable, so the interface remains workable while individual services are being rebuilt.
What can be inspected
The record is useful for architecture decisions rather than for outcome claims: service decomposition and where the boundaries were drawn, authentication using token plus double-submit protection, gateway routing, real-time presence over WebSocket, and observability through metrics endpoints. It was collaborative work, so credit is shared. Nothing here asserts adoption, enrolment numbers, or commercial performance for any institution.
Page focus
Inspect a learning-platform implementation spanning course discovery, learner journeys, administration, and maintainable content operations.
What to inspect
Review visible product behavior, workflow decisions, interfaces, and technical constraints separately from outcomes requiring client evidence.
Measurement and limits
Evaluate Elms Learn with observable checks relevant to this route. Record material changes when the underlying offer, system, evidence, or dependency changes. Technical eligibility or deployment alone does not guarantee rankings, traffic, enquiries, revenue, accessibility compliance, or operational improvement.