Skip to main content

Overview

This document presents the architecture design for a User Service built on the AWS Serverless Framework. The service handles CRUD operations on related User and Email entities, using DynamoDB with a single-table design pattern and AWS Cognito for authentication.

Key Requirements

RequirementSolution
AuthenticationAWS Cognito with JWT tokens
Data StorageDynamoDB single-table design
API LayerAPI Gateway + Lambda
Inter-ServiceEventBridge pub/sub
InfrastructureServerless Framework + Terraform

Design Principles

Every function, handler, and data model is strongly typed. No any types. Generics for reusable patterns. Type inference for cleaner consumer code.
User and Email entities in one table. Designed for access patterns, not normalized relations. Atomic transactions where needed.
Loose coupling via EventBridge. Services react to events, not direct calls. Dead Letter Queues for failure handling.
JWT validation at API Gateway. User ID from token claims only. Rate limiting on sensitive operations.

Document Structure

SectionWhat You’ll Learn
ArchitectureHigh-level system design and component interactions
Data ModelDynamoDB table schema, GSIs, and access patterns
AuthenticationCognito setup, token flow, and authorization
API DesignEndpoints, request/response schemas, edge cases
Inter-ServiceEventBridge events, consumers, failure handling
DevOpsCI/CD, monitoring, scaling, infrastructure as code
Hard PartsTechnical challenges and their solutions

Day 1 Scope

This design is time-boxed to a single day of implementation. Below is what would be delivered versus what’s deferred.

Day 1 Deliverables

  • User CRUD endpoints (/users/me)
  • Single primary email per user
  • Cognito integration with post-confirmation trigger
  • Basic EventBridge publishing (user.created, user.deleted)
  • Terraform: Cognito User Pool, DynamoDB table, EventBridge bus
  • Serverless Framework: Lambda handlers, API Gateway with authorizer
  • Manual deployment to staging

Deferred to Future Iterations

  • Multiple emails per user with verification flow
  • Transactional outbox pattern (accept at-least-once initially)
  • Full CI/CD pipeline with integration tests
  • Comprehensive CloudWatch dashboard
  • Provisioned concurrency optimization
  • Admin endpoints (GET /users/{userId})

Trade-off Rationale

DecisionDay 1 ApproachFull ImplementationWhy Defer?
Multi-emailSingle email onlyFull CRUD with verificationReduces transaction complexity
Event deliveryDirect publish (may lose events)Outbox patternAcceptable for MVP; add if reliability issues arise
CI/CDManual serverless deployGitHub Actions with staging/prodPipeline setup takes 2-3 hours
MonitoringCloudWatch Logs + basic alarmsFull dashboard + X-RayCan add incrementally
The goal is a working, deployable service by end of day. Complexity is added only when it solves a real problem, not preemptively.