Featured System

LuisDF.com Architecture

A visual overview of the serverless AWS architecture behind this website, private authentication, and the Health Agent briefing workflow.

This private workspace is protected using Google Identity, Amazon Cognito, and JWT authorization at API Gateway. The Health Agent uses the authenticated Cognito subject to isolate every athlete’s profile, credentials, briefing jobs, results, and notification preferences.

Briefing generation is asynchronous: the API validates and queues a job, a dedicated worker performs Garmin, weather, training-load, and OpenAI work, and the browser polls durable job status before loading the completed result.

LuisDF.com serverless AWS architecture diagram including private authentication and Health Agent briefing workflow

How the system works

Website and services, from request to completion

The diagram separates the platform into four flows. Together they keep the public website fast, protect private health data, move long-running work away from HTTP timeouts, and notify the athlete only after a briefing is safely stored.

01

Website delivery

Route 53 sends luisdf.com traffic to CloudFront. CloudFront provides TLS, caching, and global delivery while the website’s HTML, CSS, JavaScript, and architecture assets live in S3. GitHub is the source of truth; deployments copy only intended website files to S3 and invalidate CloudFront when an immediate refresh is required.

02

Identity and access

Private pages start a hosted sign-in through Amazon Cognito and Google. Google’s email and verified-email claims are mapped into Cognito, which issues JWT access tokens and supplies Admin or User group membership. API Gateway validates the JWT before invoking the API. Backend code then uses the token’s immutable Cognito subject to scope all reads and writes.

03

Asynchronous briefing jobs

POST /briefings/run validates the requested date and run options, creates a user-owned DynamoDB job, sends its ID to SQS, and returns 202 Accepted. The browser polls GET /briefings/jobs/{id} and saves the active ID locally so polling can resume after a refresh.

04

Briefing worker and data

The SQS-triggered worker claims one job at a time, with controlled concurrency and a dead-letter queue. It loads the athlete profile and KMS-encrypted personal credentials, retrieves Garmin and weather data, calculates training load, requests the OpenAI coaching summary, and stores dated output in private S3. Only then does it update the athlete’s latest-briefing pointer.

05

Results and failures

Job state moves through queued, running, completed, completed with warnings, or failed. Status records contain safe codes, timestamps, warnings, and a correlation ID—not credentials or raw internal exceptions. Once complete, the browser calls GET /briefings/latest to render the private dashboard.

06

Email notifications

A separate SQS queue triggers the notification Lambda after completion. It checks the athlete’s opt-in settings, resolves the current verified Cognito email, and sends through Amazon SES from training@luisdf.com. Job-specific idempotency prevents duplicate messages, while retries and a dead-letter queue protect temporary failures.

Security and operations

Private S3 objects and DynamoDB records are not public. IAM grants each Lambda only the services it needs; KMS protects athlete-supplied credentials; Secrets Manager holds platform configuration; CloudWatch captures structured operational logs. Unauthenticated API requests are rejected before Lambda, and responses expose sanitized errors with correlation IDs.