Cornell CMSX: Lead Software Engineer

CMSX is Cornell’s course management platform, used by thousands of students and instructional staff every semester. I own architecture and reliability for the platform — a long-running modernization effort moving the system from legacy JSP and servlet-era patterns toward a REST-first architecture, plus the operational tooling that makes running it at that scale tractable.

The legacy implementation mixed server-side rendering concerns with application logic, relied heavily on session-bound XML data, and made feature development expensive. A major part of my work has been designing and shipping JSON-based endpoints with clear HTTP semantics, then pairing those APIs with a modern React frontend that can handle dense staff workflows while staying responsive and maintainable — including leading a migration of 17K+ lines of legacy JSP to React/TypeScript with 95% test coverage and zero downtime.

On the backend, I use functional-style Java patterns such as Maybe<T> and Result<T> to make nullability and failure paths explicit in types rather than implicit in exceptions and defensive checks. This has made validation and control flow more composable, especially for large endpoints with many optional fields and nested operations. I also use builder-based entity updates with JPA to preserve transactional integrity and keep multi-field updates atomic.

On the frontend, I focus on information-dense but usable interfaces using React and MUI/MUI Data Grid patterns, with typed data models and runtime validation to catch contract mismatches early.

Building the observability stack

Running WildFly and a legacy MySQL instance in production with no visibility into either was the biggest operational risk on the platform, so I built the monitoring stack from scratch. On the metrics side, that meant standing up Prometheus alongside a custom MySQL exporter (with a dedicated, least-privilege exporter DB user) and scraping WildFly/JVM metrics directly, then building out Grafana dashboards — a WildFly/JVM view, a MySQL view, and a single-screen overview — so the state of the platform is visible without digging through logs first.

On the logging side, I overhauled application logging onto SLF4J and Logback, wired an Alloy pipeline that parses WildFly’s JSON stdout and promotes level/logger to Loki labels while keeping requestId/netid/course queryable, and moved Slack error reporting into a proper monitoring package instead of being scattered across controllers.

The alerting layer ties both together: Grafana alert rules (WildFly down, MySQL down, high ERROR log rate, and more) route through severity-tiered Slack contact points — critical, warning, info — each with its own notification cadence, so a paging-worthy outage and a noisy warning don’t compete for the same channel’s attention. The result is that incidents get caught and triaged from dashboards and Slack instead of from a student’s bug report.