Architectural Overhaul: Migrating 300K Daily Sessions to a Hybrid JWT System

The Challenge: Cryptographic Burden vs. User Needs

Our custom e-commerce platform faced critical architectural friction caused by an aging authentication model using proprietary ASP.NET FormsAuthenticationTickets. This secure, cookie-based system created severe problems that compromised both security control and the user experience (UX):

1. Maintenance Bottleneck: The system required a global, shared machine key for all servers to validate and decrypt the authentication cookie. Any attempt to update the key—for security or migration reasons—instantly invalidated all user cookies, forcing all 250,000 users to log out simultaneously.
2. Poor UX & Retention: Customers were logged out after only 45 minutes of inactivity (when the underlying session data expired), leading to high friction and complaints. Extending the old cookie window was a massive security liability.
3. No Revocation Capability: Due to the machine key dependency, we had no ability to instantly revoke a single compromised account without causing a massive service disruption for every other customer.

The goal was to move to a modern JWT standard to facilitate future ASP.NET Core migration, satisfy a 30-day user retention requirement, and introduce real-time security control.

The Solution: Risk-Based Hybrid Architecture with JWTs

As the technical lead, I designed and oversaw the full-stack transition to a hybrid JWT (JSON Web Token) system. This approach prioritized balancing low-friction access for purchasing with zero-tolerance security for sensitive data.

1. Risk-Based Authorization with Roles

   Instead of a single "logged-in" state, we segmented authorization using roles within the JWT claims:

   • Low-Risk Access (30 Days): Upon a successful refresh, the user was assigned the 'LIMITED' role. This allowed them to make purchases, view order history, and use site notifications—crucial for customer retention.
   • High-Risk Access (60 Minutes): Upon a fresh login, the user was assigned the 'FULL' role for 60 minutes. This granted permissions to sensitive actions like editing billing information or changing account details, enforcing fresh proof of identity for high-risk access.
2. Compromise Detection and Data Integrity

   To enable the vital ability to revoke authentication instantly and safely, we implemented a controlled, stateful refresh mechanism:

   • The system uses a unique refresh token and a client fingerprint (stored in the database) as a composite key.
   • Upon JWT expiration (every hour), the refresh token is presented. We poll the database to verify the token and check for suspicious activity, such as a mismatched fingerprint or known compromised tokens tied to the account.
   • If a mismatch is detected, the refresh token is immediately revoked. This ensured that any bad actor was locked out upon the next hourly token expiration, successfully shortening the vulnerability window to minutes instead of days.
   • We designed a data purge mechanism to automatically clean up refresh tokens and associated data after 45 days, preventing unnecessary database bloat and maintaining performance.
3. Seamless Go-Live and Failover

   To mitigate deployment risks for our live traffic:

   • We utilized Feature Toggles to activate the new JWT system.
   • Upon activation, if a customer had a valid legacy FormsAuthTicket cookie, we pulled the required data and instantly issued a new JWT on the spot, avoiding the need for the customer to re-authenticate during the migration.
   • The old FormsAuthTicket cookie was left intact as a failback plan, allowing us to revert the feature toggle instantly in case of an issue.

The Outcome: Measurable Success

The new hybrid authentication system successfully achieved all technical and business objectives, future-proofing the platform's core security layer:

• User Retention & UX: Customer complaints regarding frequent sign-ins vanished. Customers are no longer forced to log in to view critical notifications, which helped drive website conversion to near historic highs.
• Scalability: We eliminated the dependency on a single cryptographic machine key, drastically improving security maintenance flexibility and deployment speed.
• Security Posture: We gained the critical ability to instantly revoke authentication for compromised accounts through the refresh token mechanism, a feature previously unavailable, dramatically reducing security risk.

Designing Data Reliability: From Promotional Feeds to Transactional Integrity at Scale

The Challenge: Data Silos, Performance Bottlenecks, and Pricing Complexity

My responsibilities extended beyond simple database administration to include the individual design, implementation, and ownership of critical data flows used by multiple departments. We faced three core challenges that required deep structural intervention:

1. Promotional Pricing Complexity: We needed to provide our Oracle Responsys promotional email platform with fully aggregated, read-ready product data, including complex pricing schedules. The email system's limited template logic meant I had to transform and apply all necessary pricing and promotion logic before data delivery, requiring multi-table joins and data preparation outside the main application database.
2. Application Read Contention: The primary website database suffered from heavy load, requiring complex joins to retrieve basic product attributes (from Merchandising and Marketing feeds). This increased query execution time and DB load for every page view and the inability to take invoices in the event of our DB was overwhelmed.
3. Transactional Integrity & Scale: Order-taking stored procedures were complex and high-risk, requiring precise transactional logic to ensure data input from web APIs translated correctly into our core invoicing schema. This system needed to maintain all-or-nothing integrity while scaling from a baseline of 11,000 invoices per day to peak loads exceeding 17,000 invoices per day during periods of heavy traffic (like the COVID surge).

The Solution: Read-Optimization and Enforced Transactions

As the responsible Database Developer/Administrator for data integration within my domain, I implemented and enforced targeted structural solutions, ensuring I was the single point of control for data entering these systems:

1. Maintaining the Read-Optimized Data Layer

   I was responsible for maintaining the critical ETL process that fed our existing Flattened Database. This denormalized, read-optimized schema was essential for minimizing complex joins and reducing database load on web-facing systems. My role involved continually updating and adapting the incoming data feeds to meet new business data requirements, ensuring the public-facing product data remained accurate and highly performant for front-end consumption.

2. Advanced Data Transformation for Marketing

   For the Oracle-fed promotional email system, I built the ETL processes from scratch to construct complete product records that correctly reflected time-based pricing schedules. This involved applying complex data transformations and joins, ensuring every email event had the accurate, pre-calculated pricing data required for the event's live duration.

3. Transactional Integrity for Invoicing

   I was responsible for maintaining the stored procedures for the core order-taking process. Data input was handled within explicit transactions, ensuring that the transformation of web API data into the final invoice schema was always an all-or-nothing operation. This commitment to transactional safety provided the highest level of data integrity for our revenue records and ensured the system could gracefully handle the massive increase in transactional volume.

The Outcome: Business Mastery and Reliability

This deep involvement in data architecture and flow had profound benefits:

• Reliability and Performance at Scale: The underlying data systems proved resilient, successfully scaling to handle 17,000 invoices per day without stability issues, validating the read-optimization and transactional design decisions under extreme load.
• Domain Expertise: Through building and maintaining these interconnected systems (from merchandising to marketing to invoicing), I gained a comprehensive understanding of how systems impact one another—allowing for rapid identification of root causes and responsible data owners when production issues arose.
• Enforced Standards: My oversight ensured all database development in the responsible area was optimized for performance, with necessary indexes and relationships correctly applied before deployment.

Orchestrating a Resilient Framework Migration

The Challenge: Managing Risk in a Live, High-Traffic System

The primary challenge was not a broken architecture, but the operational risk of modernizing our technology stack. We needed to migrate legacy frameworks (like Angular JS and older React apps) to a modern, type-safe functional language (Elm) to gain performance and reliability.

However, a "big bang" or all-at-once replatforming was far too risky for a site handling 300K daily sessions. We faced two key challenges:

1. Minimizing Migration Risk: How do we replace critical components piece-by-piece, in a controlled, low-risk manner, without causing service disruptions?
2. Maintaining SEO & Performance: During this progressive migration, we had to ensure our server-side rendering (for SEO and first-page paint) remained perfectly intact and that we could prove the benefits of the new framework.

The goal was to execute a large-scale framework modernization, prove its benefits (like Elm's smaller bundle size and type safety), and do so with minimized deployment risk.

The Solution: Orchestration of Modular Delivery and Framework Swapping

As a leader on the team, I focused on orchestrating the deployment and utilization of the existing Micro-Frontend architecture, leveraging its core features—granular delivery via Razor Pages and Redis-backed feature toggles—to achieve this migration.

1. Targeted, Page-Specific Bundles

   The architecture's core strength was that each Razor Page was responsible for delivering only the specific React or Elm bundle it required. This existing separation was the key that unlocked our ability to migrate.

2. SEO-First Rendering

   We leveraged the server-side capabilities of ASP.NET/Razor to utilize View Models for initial server-side rendering. This ensured that all critical data required for first page paint and strong SEO was delivered instantly, a standard that had to be maintained for any new framework component.

3. Granular Caching and Edge Delivery

   Each Micro-Frontend JS bundle was delivered via Akamai Edge Caching. This provided Targeted Cache Busting—a change on one page only invalidated the cache for its specific, small bundle—which was critical for deploying and testing new framework components without affecting the rest of the site.

4. Progressive Migration and Deployment Control

   This was the core of the solution. I led and orchestrated the effort to convert pages, component by component, from older frameworks to Elm, simply by replacing one Micro-Frontend bundle at a time.

   • Progressive Replacement: This yielded type safety with no runtime exceptions and faster page loads from Elm's smaller bundle size.
   • Reduced Risk: We used Redis-backed feature toggles (hydrated into the DOM or used in the ASP.NET Controller) to dynamically swap between implementations. This allowed us to deploy the new Elm components "dark" and then toggle them on for limited test groups, accelerating refactoring with near-zero risk.

The Outcome: Speed, Autonomy, and Scalability

This strategic utilization of the Micro-Frontend architecture achieved critical gains across performance and engineering velocity:

• Accelerated Migration: We successfully managed several major framework upgrades, including replacing large portions of the site with Elm, reducing technical debt and increasing type safety without the risk of an all-or-nothing replatforming event.
• Targeted Reliability: The increased type safety of Elm and the reduced risk from feature toggles led to improved refactor success and speed with fewer post-deployment issues.
• Improved Web Performance: As a direct result of the Elm migration, bundle sizes were significantly smaller, drastically improving initial page load times and conversion rates.

Building a Resilient, Multi-Tenant CMS Platform with Elixir/Phoenix LiveView

(Note: "Project Chef" is a codename for an unlaunched commercial platform, used here to protect intellectual property.)

The Challenge: Creating a Scalable, Self-Service Platform for Non-Technical Users

Project Chef began as a technical challenge: design and build a self-service web platform that empowers small business owners—most with little to no technical background—to manage a modern, mobile-friendly website without writing a single line of code.

The challenge was multifaceted:

1. Multi-Tenancy and Automation: Each food truck needed its own isolated site (with dynamic subdomains), yet all had to run off a single, shared codebase. Manual setup per truck was not an option—the platform had to scale automatically from a single tenant to hundreds.
2. Simplicity Without Compromise: The core content management system (CMS) needed to be intuitive enough for non-technical users, while still offering robust flexibility in managing menus, locations, schedules, and brand themes.
3. Operational Efficiency: As a solo developer, I needed to design for minimal ongoing maintenance—automated deployments, image cleanup, background jobs, and billing all had to be handled seamlessly and reliably by the application itself.

The goal was to create a profitable, low-maintenance SaaS that small business owners could adopt quickly, while keeping engineering complexity manageable through functional design.

The Solution: A Fully Automated Phoenix & Elixir-Based SaaS Foundation

I architected Project Chef as a modular Elixir/Phoenix application with a focus on functional composition, fault tolerance, and automation. This was a proving ground for Elixir's capabilities in building real-world, highly available SaaS products.

1. Multi-Tenant Architecture via Dynamic Subdomains

   Each food truck operates under its own dynamic subdomain (e.g., taco-palace.chef-app.io), dynamically routed and isolated within Phoenix.

   • No manual DNS or configuration steps are required—when a new food truck signs up, its dedicated subdomain goes live automatically.
   • This structure allows full separation of data per tenant (strict client data isolation) while maintaining a shared, efficient runtime environment.
2. Zero-JS Content Management via LiveView

   Owners manage their websites through a pure LiveView-based CMS, handling menus, pages, images, and color themes in real time.

   • EasyMDE (Markdown) was integrated for rich content editing while maintaining a lightweight, server-driven architecture.
   • The LiveView design ensures instant, real-time feedback and a highly interactive experience with significantly fewer moving parts compared to a traditional SPA + API approach.
3. Scalable Storage and Resilient Background Processing

   Image uploads are handled by the server but immediately routed to DigitalOcean Spaces using presigned uploads, keeping application performance high and managing file costs low.

   • Background tasks—such as image cleanup, schedule updates, and notifications—run reliably through Oban, leveraging Elixir's supervision trees for built-in fault tolerance and observability.
4. Operational Readiness

   The application includes a robust configuration supporting separate development, staging, and production environments, and is designed for automated CI/CD deployment to Fly.io. Stripe integration handles all billing and subscription events, fully synchronized via webhooks to ensure transparent handling of the user lifecycle.

The Outcome: A Lightweight, Production-Ready Prototype

Project Chef successfully proves that modern Elixir systems can offer both powerful developer ergonomics and enterprise-grade business scalability:

• Rapid Tenant Creation: The system demonstrates the ability for food trucks to onboard in seconds with zero manual setup.
• High Reliability: Leveraging Elixir's functional nature and tools like Oban ensures the platform is resilient, self-healing, and designed for near-zero operational overhead.
• Architectural Philosophy: This project pushed my Elixir expertise deeper into multi-tenant design, LiveView UX, and operational automation, reflecting the same engineering values—functional design, composable systems, and developer empathy—I bring to every project.