When we launched getowl, we handled a few hundred redirects per day. Today, we serve over 90 million clicks per month with sub-50ms p99 latency worldwide. This is the engineering story of how we got there.
Architecture Overview
Our redirect infrastructure runs on three core AWS services:
- Lambda@Edge — Executes redirect logic at 400+ CloudFront edge locations worldwide
- DynamoDB — Stores link configuration with single-digit millisecond reads
- CloudFront — CDN layer that handles TLS termination and caching
Why Lambda@Edge?
Traditional redirect services route every request through a central server. This means a user in Mumbai hitting a link hosted in us-east-1 adds 200-300ms of network latency before the redirect even starts.
With Lambda@Edge, the redirect logic executes at the CloudFront edge location closest to the user. A click from Mumbai is processed at the Mumbai edge — no cross-region roundtrip.
DynamoDB at Scale
We use DynamoDB's on-demand capacity mode with a simple partition key schema: the short code (or domain#code for custom domains). This gives us:
- Single-digit millisecond reads regardless of table size
- No capacity planning — scales automatically with traffic
- Global tables for multi-region reads (coming soon)
The Numbers
- p50 latency: 12ms
- p99 latency: 48ms
- Uptime: 99.99% over the last 12 months
- Peak throughput: 4,200 redirects/second
- Cost per redirect: $0.000003
Lessons Learned
- Edge computing changes everything — Moving logic to the edge eliminated 80% of our latency
- DynamoDB on-demand is worth the premium — We tried provisioned capacity and got burned by traffic spikes
- Custom domain SSL is the hardest part — ACM certificate provisioning and CloudFront alternate domain management is our most complex subsystem
- Monitoring at the edge is tricky — CloudFront logs have a 5-15 minute delay; we built real-time analytics via Tinybird for instant visibility