AI Hackathon Review Platform on AWS
Serverless review platform with a fast read path via FastAPI and DynamoDB, and an async write path using SQS and Lambda....
Takes 30 seconds • No credit card required
Tags
Architecture Description
You are a solutions architect. Create a clean, high-level system architecture diagram for an AI-powered hackathon review platform. The system has two paths: READ PATH (instant): A judge clicks View Detail, hits FastAPI with Cognito auth, queries DynamoDB, returns rendered HTML. WRITE PATH (async): An admin clicks Run Review, hits FastAPI with Cognito auth, creates a job in DynamoDB, enqueues to SQS, picked up by Lambda running a Strands Agent which fans out to 5 parallel judge agents, fans back in to a synthesis step, stores results back to DynamoDB. Seven layers top to bottom: 1. Presentation - Browser for Judge and Admin 2. Application - FastAPI with AWS Cognito 3. Data - AWS DynamoDB 4. Messaging - AWS SQS as the decoupling boundary between sync and async 5. Processing - AWS Lambda with Bedrock AgentCore and Strands Agent running 5 parallel judges that fan into synthesis 6. AI/LLM - AWS Bedrock using Claude Sonnet 4.5 7. External - GitHub API Diagram requirements: - Show both read and write paths clearly - Show the fan-out and fan-in of the 5 judges - Service names only, no table names, field names, or internal details - Keep it minimal, one box per service, labels on arrows only where needed
Creator Notes(1)
This is an example of a representative architecture for the AI Hackathon application created by Vishu. The Hackathon application uses agentic patterns.
about 15 hours ago
Community Reviews(1)
about 16 hours ago
I think the biggest production risk is putting a long-running, fan-out/fan-in AI orchestration inside a single Lambda behind SQS. That looks elegant on the diagram, but in practice you’re coupling queue retry semantics, Lambda timeout/concurrency limits, Bedrock latency, and GitHub API variability into one failure domain. If one of the 5 judge calls or the synthesis step is slow or fails, you risk duplicate reviews, partial writes to DynamoDB, poison messages, and hard-to-debug reprocessing unless you add idempotency keys, DLQs, per-step status, and result versioning. I would strongly consider Step Functions for the write path orchestration instead of a monolithic worker Lambda. It gives you explicit parallelism, retries by step, timeout control, and auditability. I also don’t see a clear strategy for DynamoDB access patterns: the read path is “instant,” but rendered HTML detail views can become inconsistent if async writes overwrite prior results without state transitions. I would want explicit job states, optimistic locking, and a reviewer-facing “in progress vs complete” model before calling this production-ready.
Sign in to share your review on this architecture
Sign in to reviewOpen an interactive version — fork it, generate AI variants, or share it with your team.
What You'll Get
Start Customizing
Make this template your own
Share
Statistics
Creator
Expert cloud architect with 463 multi-cloud infrastructure deployments across AWS, Azure, GCP, and OCI, leveraging 12 distinct technologies to design and deploy robust architectures. Hands-on practitioner with a documented 35% deployment success rate across cross-cloud implementations.
Details
Estimated monthly cost
$12.64/month
Services Used
10 cloud services in this architecture
Ready to build this?
Clone this architecture into your workspace and deploy it to your cloud account.
Deploy This ArchitectureTakes 30 seconds • No credit card required