​

Radar Migration Guide: Simplified Internal Chat API Integration

​

What Changed

​

Before

• Processor Lambda: 2048MB memory, 15min timeout, VPC required
• Dependencies: ~20 Python packages (agno, anthropic, duckdb, matplotlib, pandas, numpy, yfinance, exa, polygon, psycopg2, seaborn, etc.)
• Code: ~500+ lines across multiple files (agents, prompts, tools, utils)
• Database: Direct Supabase/PostgreSQL connections
• Charts: S3 bucket for chart storage
• Architecture: Complex multi-agent system with tools

​

After

• Processor Lambda: 512MB memory, 10min timeout, no VPC
• Dependencies: 2 Python packages (boto3, requests)
• Code: ~200 lines in single handler.py file
• Database: No direct connections (uses internal API)
• Charts: None (removed)
• Architecture: Simple HTTP client calling internal chat API

​

Benefits

​

Setup Instructions

​

Step 1: Add Token to Vercel

YuFqc9tIfFt3Z2kxlYfv8ZLxV1GzYUvMBhrGkYNi+KA=

1. Go to Vercel Dashboard → Your Project → Settings → Environment Variables
2. Add new variable:
   • Name: INTERNAL_API_TOKEN
   • Value: YuFqc9tIfFt3Z2kxlYfv8ZLxV1GzYUvMBhrGkYNi+KA=
   • Environments: Production, Preview, Development
3. Click “Save”
4. Redeploy your application to apply changes

curl -X POST https://cfosilvia.com/api/chat/internal \
  -H "Authorization: Bearer YuFqc9tIfFt3Z2kxlYfv8ZLxV1GzYUvMBhrGkYNi+KA=" \
  -H "Content-Type: application/json" \
  -d '{
    "clerkId": "user_test",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

​

Step 2: Deploy CDK Stack

cd aws
uv run cdk deploy RadarStack-dev

• Secret: dev-RadarInternalApiToken (contains the token)
• Updated Lambda: Uses 512MB, no VPC, calls internal API
• Same DynamoDB tables, SQS queue, API Gateway

​

Step 3: Verify Deployment

aws cloudformation describe-stacks --stack-name RadarStack-dev \
  --query 'Stacks[0].Outputs'

• InternalApiTokenSecret: Name of the secret (should be dev-RadarInternalApiToken)
• ApiUrl: Your API Gateway URL

​

Step 4: Test the Processor

# Get your API Gateway URL from CloudFormation outputs
API_URL="https://YOUR_API_ID.execute-api.us-east-1.amazonaws.com/prod"

# Create a test schedule
curl -X POST "$API_URL/schedules" \
  -H "X-User-Id: your_clerk_id" \
  -H "Content-Type: application/json" \
  -d '{
    "promptTemplate": "What is my current net worth?",
    "scheduleConfig": {
      "frequency": "DAILY",
      "timeUtc": "06:00",
      "timezone": "UTC"
    }
  }'

# Trigger the schedule manually
curl -X POST "$API_URL/trigger" \
  -H "X-User-Id: your_clerk_id" \
  -H "Content-Type: application/json" \
  -d '{
    "scheduleId": "YOUR_SCHEDULE_ID"
  }'

# Check the result
curl "$API_URL/results" \
  -H "X-User-Id: your_clerk_id"

​

Architecture Overview

​

Request Flow

1. EventBridge (6am UTC) → Orchestrator Lambda
2. Orchestrator → Queries DynamoDB for due schedules
3. Orchestrator → Sends schedules to SQS FIFO queue
4. SQS → Triggers Processor Lambda (batch of 10)
5. Processor → Calls internal chat API at cfosilvia.com
6. Internal API → Uses all tools (DuckDB, Python, YFinance, etc.)
7. Internal API → Returns complete analysis
8. Processor → Stores result in DynamoDB
9. Processor → Updates schedule nextRun timestamp

​

Data Flow

User creates schedule → Stored in DynamoDB
                     ↓
          Orchestrator finds it daily
                     ↓
          Processor calls internal API
                     ↓
          Internal API uses all tools
                     ↓
          Result stored in DynamoDB
                     ↓
          Frontend displays result

​

Monitoring

​

CloudWatch Logs

/aws/lambda/dev-RadarProcessor

• Processing radar for user {clerk_id}
• Successfully processed radar {radar_id}
• Error calling internal chat API

/aws/lambda/dev-RadarOrchestrator

​

DynamoDB Tables

PK: USER#{clerk_id}
SK: SCHEDULE#{schedule_id}

PK: USER#{clerk_id}
SK: RESULT#{schedule_id}#{timestamp}

​

Debugging

aws logs tail /aws/lambda/dev-RadarProcessor --follow

aws sqs get-queue-attributes \
  --queue-url YOUR_QUEUE_URL \
  --attribute-names All

aws dynamodb scan \
  --table-name dev-RadarSchedulesV2 \
  --limit 10

​

Troubleshooting

​

Error: “Failed to retrieve API token”

# Check if secret exists
aws secretsmanager describe-secret \
  --secret-id dev-RadarInternalApiToken

# Check Lambda IAM role has permission
aws iam get-role-policy \
  --role-name RadarStack-dev-RadarProcessor-Role \
  --policy-name RadarStack-dev-RadarProcessor-Policy

​

Error: 401 Unauthorized from internal API

1. Get token from AWS:

aws secretsmanager get-secret-value \
  --secret-id dev-RadarInternalApiToken \
  --query SecretString --output text

2. Compare with Vercel environment variable
3. Update if different

​

Error: Timeout calling internal API

1. Check Vercel function logs for the internal API
2. Consider breaking complex queries into smaller parts
3. Increase processor timeout if needed (CDK stack)

​

Error: No results in DynamoDB

1. Check orchestrator ran at 6am UTC:

aws logs filter-log-events \
  --log-group-name /aws/lambda/dev-RadarOrchestrator \
  --start-time $(date -d '1 day ago' +%s)000

2. Check SQS for messages
3. Check processor logs for errors

​

Cost Comparison

​

Before (Complex Agent)

• Lambda Memory: 2048MB
• Lambda Duration: ~5-10 minutes per execution
• VPC: NAT Gateway ($0.045/hour =$32.40/month)
• Network Transfer: VPC to Supabase
• S3: Chart storage and bandwidth

​

After (Internal API)

• Lambda Memory: 512MB
• Lambda Duration: ~30-60 seconds per execution
• VPC: None
• Network Transfer: Minimal (just API calls)
• S3: None

​

Migration Checklist

• Simplify processor handler.py to call internal API
• Update requirements.txt (remove all complex dependencies)
• Update Dockerfile (remove agent/prompt/tool copies)
• Modify CDK stack (remove VPC, reduce memory, add API token)
• Remove agents folder
• Remove prompts folder
• Remove tools folder
• Remove utils folder
• Update API handler (remove chart endpoints)
• Remove chart routes from CDK stack
• Add INTERNAL_API_TOKEN to Vercel
• Deploy CDK stack to AWS
• Test processor with sample schedule
• Monitor CloudWatch logs
• Verify cost reduction

​

Rollback Plan

1. Restore the old processor code from git:

git checkout HEAD~1 -- aws/radar/lambdas/processor/

2. Restore the old CDK stack:

git checkout HEAD~1 -- aws/radar/stack.py

3. Redeploy:

cd aws
uv run cdk deploy RadarStack-dev

​

Support

1. Check Vercel function logs for internal API
2. Check CloudWatch logs for Lambda functions
3. Check DynamoDB tables for data
4. Review this guide’s troubleshooting section

​

Related Documentation

• Internal Chat API Documentation
• Internal API Setup Guide
• Radar API Documentation