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.
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.
01Website 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.
02Identity 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.
03Asynchronous 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.
04Briefing 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.
05Results 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.
06Email 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.