AWS CDK Link Shortener Part 2: Core Functionality & API Development
Building the redirect engine, analytics collection, and API Gateway configuration. Real performance optimizations and debugging strategies from handling millions of daily redirects.
AWS CDK Link Shortener Part 2: Core Functionality & API Development
A link shortener is mostly a redirect engine: the short-code lookup and the HTTP 301 response are the only operations on the critical latency budget, and both have to stay under the typical user-perceived-instant threshold (around 200ms) even at high concurrency. The business logic around that hot path (analytics, rate limiting, link expiration, custom slugs) must not block the redirect; every feature added to the redirect handler directly costs latency at the edge.
Part 1 of this series set up the foundation (DynamoDB table, API Gateway, base Lambda). This post covers the core functionality: the redirect Lambda with DynamoDB caching, the API for creating and managing short codes, analytics event emission through a side channel, and the error-handling patterns that keep the redirect fast when upstream services degrade.
The Redirect Engine: Where Speed Matters
The redirect handler is the heart of your link shortener. Every millisecond counts because users expect instant redirects. Here's our production-tested implementation:
Analytics: The Business Intelligence Layer
Analytics made our link shortener valuable beyond just convenience. Here's how we collect and store click data:
API Gateway: The Front Door
Here's our CDK configuration that handles high traffic loads efficiently:
Performance Lessons from Production
After handling production traffic at scale, here are the performance patterns that actually matter:
1. Connection Pooling Saves 50ms Per Request
The DynamoDB client configuration above includes connection pooling. Without it, each Lambda cold start creates new connections, adding 50-100ms latency. With proper pooling:
- Cold start redirect: ~200ms
- Warm redirect: ~15ms
- Connection reuse rate: 85%
2. Async Analytics Don't Block Users
Initially, we tracked analytics synchronously. Bad idea. Users don't care if analytics fail, but they definitely care if redirects are slow. Fire-and-forget analytics collection reduced our P95 response time from 300ms to 45ms.
3. DynamoDB Projections Matter
Using ProjectionExpression in our GetItem calls reduced response sizes by 60%. We only fetch what we need for redirects: originalUrl, expiresAt, clickCount. Analytics queries use a separate GSI.
Debugging Production Issues
CloudWatch Insights Queries That Save Your Day
Lambda Performance Monitoring
Testing Your Redirect Engine
What's Next
In Part 3, we'll add the security features that keep your service from becoming a spam vector: rate limiting, click fraud detection, and custom domain setup with SSL certificates.
We've built a solid redirect engine, but production taught us that security isn't optional - it's what separates a hobby project from a business-critical service. See you in the next part where we'll implement the anti-abuse measures that kept our service running during attempted spam attacks.
References
- docs.aws.amazon.com - AWS CDK Developer Guide.
- github.com - AWS CDK source repository and release notes.
- docs.aws.amazon.com - Lambda functions: execution model and scaling.
- docs.aws.amazon.com - Amazon API Gateway Developer Guide.
- nodejs.org - Node.js official documentation.
- typescriptlang.org - TypeScript Handbook and language reference.
- github.com - TypeScript project wiki (FAQ and design notes).
- web.dev - web.dev performance guidance (Core Web Vitals).
- docs.aws.amazon.com - AWS Overview (official whitepaper).
- cloud.google.com - Google Cloud documentation.
AWS CDK Link Shortener: From Zero to Production
A comprehensive 5-part series on building a production-grade link shortener service with AWS CDK, Node.js Lambda, and DynamoDB. Real war stories, performance optimization, and cost management included.