TableTheory Architecture Patterns
This guide outlines common architectural patterns and integration strategies for building robust, scalable, and cost-effective applications using TableTheory.
Table of Contents
- Request Flow
- Serverless Integration
- Data Access Layer
- Key Characteristics
- Observability Patterns
- Security Patterns
Request Flow
TableTheory is typically deployed within a serverless ecosystem. A common request flow looks like this:
graph TD
A[Client] --> B(API Gateway);
B --> C(AWS Lambda - TableTheory App);
C -- DynamoDB API --> D[DynamoDB Table];
C -- CloudWatch Logs --> E[CloudWatch Logs];
C -- X-Ray SDK --> F[AWS X-Ray];
Step-by-Step:
- Client sends an HTTP request (e.g., from a web browser, mobile app, or another service).
- API Gateway receives the request and routes it to a configured AWS Lambda function.
- The Lambda function, using TableTheory, processes the request:
- Initializes TableTheory (optimized for cold starts).
- Performs database operations (Create, Read, Update, Delete) against DynamoDB.
- Emits logs to CloudWatch Logs.
- Sends trace data to AWS X-Ray for performance monitoring.
- DynamoDB executes the requested operation and returns the result to the Lambda function.
- The Lambda function returns a response to API Gateway, which then sends it back to the Client.
Serverless Integration
TableTheory is designed with AWS Lambda in mind to leverage its cold start optimizations.
AWS Lambda
- Initialization: Always use
tabletheory.NewLambdaOptimized()ortabletheory.LambdaInit()in the global scope (init()function) to ensure connection reuse and minimal cold start latency. - Context Handling: Use
db.WithLambdaTimeout(ctx)to wrap your TableTheory instance with Lambda’s execution context, enabling automatic cancellation of operations before a timeout occurs. Configure custom cleanup windows withdb.WithLambdaTimeoutConfig(tabletheory.LambdaTimeoutConfig{Buffer: ...})during cold start; the default buffer is 1 second. - Memory Sizing: Tune Lambda memory based on
LambdaDB.GetMemoryStats()to balance performance and cost.
API Gateway
- Proxy Integration: Use Lambda proxy integration for simplicity, passing the full request to Lambda.
- Caching: Implement API Gateway caching for read-heavy, infrequently changing data to reduce DynamoDB load and latency.
- Throttling: Configure API Gateway throttling to protect your backend Lambda and DynamoDB from excessive requests.
Data Access Layer
TableTheory acts as a thin, type-safe data access layer over DynamoDB.
Model Definition
- Go Structs with Tags: Define your DynamoDB item schemas using standard Go structs annotated with
theorydb:"pk",theorydb:"sk",theorydb:"index:name,pk",json:"attribute_name"tags. - Encapsulation: Keep model definitions alongside business logic or in a dedicated
modelspackage.
Querying and Operations
- Fluent API: Build queries using
db.Model(...).Where(...).Index(...).All(...). - Transaction Management: Use
db.TransactWrite()for atomic operations across multiple items. - Batch Operations: Leverage
BatchGet,BatchCreate,BatchDeletefor efficient bulk processing.
Key Characteristics
Scalability
- Horizontal Scaling: DynamoDB tables scale horizontally by default. TableTheory’s API encourages patterns that distribute load across partition keys.
- Lambda Scaling: Lambda functions scale automatically based on demand, complementing DynamoDB’s scalability.
Reliability
- Fault Tolerance: DynamoDB automatically replicates data across multiple Availability Zones. TableTheory’s retry mechanisms and transaction support enhance application-level reliability.
- Connection Resiliency: Optimized HTTP clients and connection pooling within Lambda reduce transient errors.
Performance
- Low Latency: TableTheory minimizes network hops and leverages optimized marshaling/unmarshaling.
- Cold Start Reduction: Lambda-specific optimizations drastically reduce cold start times, critical for responsive serverless applications.
Cost Efficiency
- Pay-per-Use: Both Lambda and DynamoDB operate on a pay-per-use model. TableTheory encourages cost-efficient patterns (e.g., avoiding scans, using batch operations, optimizing Lambda memory).
- Minimized Overheads: Reduced boilerplate and optimized client usage translate directly to lower operational costs.
Observability Patterns
Integrate TableTheory applications with AWS observability tools.
CloudWatch Metrics
- DynamoDB Metrics: Monitor
ConsumedReadCapacityUnits,ConsumedWriteCapacityUnits,ThrottledRequests,IteratorAge(for streams). - Lambda Metrics: Track
Invocations,Errors,Duration,Throttles. - Custom Application Metrics: Emit custom metrics for business-critical events, API latency, and error rates using a metric library (e.g., Go kit metrics, Prometheus client).
AWS X-Ray Tracing
- Automatic Instrumentation: TableTheory integrates with the AWS SDK, which can be automatically instrumented by X-Ray in Lambda environments.
- Distributed Tracing: Provides end-to-end visibility into requests, from API Gateway through Lambda to DynamoDB, helping identify latency bottlenecks.
Centralized Logging (CloudWatch Logs)
- Structured Logging: Use structured logging (e.g., JSON format) within your Lambda functions to make logs easily searchable and parsable.
- Error Alarms: Set CloudWatch alarms on specific error patterns in your logs to trigger alerts.
Security Patterns
Follow these security best practices when using TableTheory.
IAM Policies
- Least Privilege: Grant only the necessary DynamoDB permissions (
dynamodb:GetItem,dynamodb:PutItem, etc.) to your Lambda execution roles. - Resource-Level Permissions: Restrict permissions to specific table ARNs where possible.
Data Encryption
- Encryption at Rest: DynamoDB supports encryption at rest by default using AWS Key Management Service (KMS).
- Encryption in Transit: All communication with DynamoDB is encrypted via HTTPS.
VPC Endpoints
- Private Connectivity: For applications within a VPC, use VPC Endpoints for DynamoDB to keep traffic within the AWS network, improving security and reducing data transfer costs.
Input Validation
- Application Layer Validation: Always validate incoming API requests and user inputs within your Lambda functions before passing them to TableTheory to prevent injection attacks or invalid data.