Authorization, Reliability & Modernization
Overview
Moody's Analytics is the crown-jewel of my recent experiences - I did so many of the coolest things of my career, in support of the digital transformation of Moodys Analytics and modernization of Moodys.com.
Two central challenges in modernizing Moodys.com were transitioning to attribute-based access control (ABAC) and stabilizing the website during its migration to elastic, cloud-native services, ECS-hosted microservices, and Adobe Experience Manager (AEM).
Legacy content and authorization services - Before
Diagram generalized for portfolio purposes — it illustrates the architecture and authorization model using abstract and fictional example data, not Moody’s systems, data, or configuration.
Attribute-Based Access Control Architect Co-lead
Architected and built a rules-based ABAC authorization system.
- Replaced a legacy authorization model requiring an 8–12 hour nightly rebuild, reducing provisioning from 12–36 hours to under two minutes across all systems.
- Re-architected onto cloud-native serverless infrastructure, resolving the site-wide latency degradation and content outages caused by legacy hardware that was slow to scale and slow to recover from traffic spikes.
- Moved authorization definitions from MongoDB query language to JSON using a simple rules engine, decoupling policy from storage technology so policies can generate queries against any data source.
- Designed resource indexes optimized for authorization-constrained queries, aligning data access patterns with attribute-based authorization requirements, and supporting increasingly granular product and content definitions.
- Delivered general-purpose authorization APIs — policy management, storage, and request evaluation — shared across all products and content types, with P99 response latency under 50 ms.
ABAC authorization — system overview
Diagram generalized for portfolio purposes — it illustrates the architecture and authorization model using abstract and fictional example data, not Moody’s systems, data, or configuration.
1 · Assignment-based permissions
2 · Resource-attribute permissions
3 · Related-resource-attribute permissions
Legacy-to-Cloud Data Synchronization (CDC) Architect Team lead
Architected a transitional change data capture (CDC) pipeline to synchronize data from multiple upstream enterprise systems into the new cloud-native authorization platform.
- Implemented lightweight SQL triggers across seven legacy tables to capture record-level changes into
{table}_changelogtables, without modifying upstream applications. - Developed asynchronous, EventBridge-scheduled polling of the changelog tables and snapshot publication to a DynamoDB-backed append-only journal.
- Designed idempotent, version-aware consumers that upserted record snapshots into the new system of record — the authorization system's DynamoDB tables — while rejecting stale updates.
- Enabled eventual consistency and incremental migration while maintaining operational independence between the legacy and cloud-native systems.
4 · Legacy-to-cloud CDC pipeline
SQL triggers →
{table}_changelog → EventBridge-scheduled poller → DynamoDB append-only journal → version-aware consumers → DynamoDB authorization tables
Why triggers instead of log-based CDC — see the architectural decision below.
Architectural Decision: Trigger-Based CDC
The source SQL database was a heavily shared, enterprise-wide system with a history of unexpected outages and concerns about operational fragility.
I proposed Debezium and AWS Database Migration Service (DMS) as potential change-data-capture (CDC) solutions for the team to consider. The senior architect and senior database administrator raised concerns about the operational risks of introducing transaction-log-based replication against such a critical and fragile database. Its broad enterprise scope also made minimizing the integration’s operational footprint particularly important.
We ultimately adopted a narrowly scoped, trigger-based CDC approach — capturing changes from seven relevant tables into dedicated changelog tables. A scheduled polling process collected those changes and published record snapshots to an append-only DynamoDB journal for downstream processing.
This reflected a collaborative architectural decision that prioritized operational risk management, explicit scope, and the constraints of the legacy environment.
Transitional Content Store Architect Solo engineer
Architected and built Transitional Content Store (TCS), a read-through caching and content-management layer. Pre-warmed the cache using four months of production URL traffic, shielding the legacy monolith from traffic spikes while insulating website functionality from backend outages.
- Architected and built caching middleware with operational controls to support surgical content management by operations team.
- Implemented a progressive caching strategy with a hybrid cache (local in-memory and remote Redis) to balance performance and durability.
- Designed a flexible caching policy engine with configurable TTLs, cache-aside patterns, and cache invalidation strategies.
- Built a monitoring and alerting system to track access patterns, cache hit rates, and cache misses.
- Eliminated dependency on SharePoint, in favor of Adobe Experience Manager.
- Eliminated dependency on Microsoft IIS 7.5, favoring cloud-native services and ECS-hosted microservices for their superior scalability and reliability.
- Incident escalations fell from 1–2 per week to one in six months while maintaining 99.99% site stability.
5 · Transitional Content Store (TCS)
read-through hybrid cache (in-memory + Redis) · configurable TTL / cache-aside / invalidation policy engine · operational content-management controls · cache hit/miss monitoring & alerting
Diagram will be sanitized and generalized for portfolio purposes — illustrating the architecture using abstract example data, not Moody’s systems, data, or configuration.
Tech & scope
Cross-squad influence: Architecture Review (partnered with tech-leads early and often on data pipelines, authorization, research, text-to-speech accessibility, and the AI Copilot), Backend Guild (reusable CDK constructs shared across squads), Testing Guild, and Observability Guild (Splunk, CloudWatch, OpsGenie).
