This Dogfood is Great

At Proxylity, we're passionate advocates for serverless architectures. Our entire business is built around enabling UDP traffic to connect directly to serverless resources, eliminating the need for our customers to manage servers. But there's an irony here - to provide this capability, we do run servers so our customers don't have to.

That's why we've embraced the concept of "dogfooding" - using our own products and principles to build our infrastructure. This article explores how we've applied serverless approaches throughout our stack, even in places where serverless traditionally hasn't been a natural fit.

Step Functions for Frontend Orchestration

One of our most interesting architectural decisions was using AWS Step Functions to orchestrate our frontend application. Traditional wisdom might suggest using a server-based API Gateway or a collection of Lambda functions, but we found Step Functions offered some unique advantages:

• Declarative workflows that clearly model our business processes
• Visual debugging capabilities that make troubleshooting easier
• Built-in state management without additional infrastructure
• JSONata integration for powerful data transformations

While this approach presented challenges, particularly around cold starts and optimizing for performance, it's given us a uniquely powerful platform for evolving our application logic. The recently added JSONata support has been a game-changer, letting us perform complex transformations without writing custom code.

EventBridge for Workflow Orchestration

Another key component of our architecture is Amazon EventBridge, which we use to coordinate workflows across our systems. This event-driven approach allows us to:

• Maintain loose coupling between services
• Scale components independently based on load
• Add new functionality without modifying existing services
• Implement complex retry logic and error handling

Our event patterns have evolved over time, but one pattern we've found particularly effective is the "command event" pattern, where events don't just notify about changes but explicitly request specific actions from downstream services.

Serverless Email Infrastructure

Email might seem like a simple problem, but building a reliable, scalable email system that handles templates, deliverability, and tracking is surprisingly complex. Rather than spinning up dedicated email servers, we've built a completely serverless email infrastructure:

• SES for reliable email delivery
• S3 for template storage
• Lambda for template rendering and personalization
• DynamoDB for tracking delivery status and engagement
• EventBridge for coordinating the email workflow

This approach has allowed us to handle everything from account verification emails to complex multi-step workflows with minimal operational overhead.

The Irony of Running Servers to Enable Serverless

We recognize the irony in our position. Proxylity runs servers - specifically, highly optimized UDP packet processors - so that our customers don't have to. But wherever possible within our own infrastructure, we apply the same serverless principles we advocate:

• Pay only for what you use
• Scale automatically with demand
• Minimize operational overhead
• Focus on business logic, not infrastructure

The UDP Gateway service itself requires running servers, but we've designed it to be as operationally efficient as possible. Meanwhile, everything around it - our dashboard, APIs, billing system, and monitoring - leverages serverless architectures.

Lessons Learned

Eating our own dogfood has taught us valuable lessons about serverless architectures:

1. Think in events, not requests. Event-driven architectures are more resilient and scalable.
2. Embrace asynchronous patterns. Not everything needs to be synchronous, and async often scales better.
3. Be pragmatic. Sometimes a small dedicated service makes more sense than trying to force everything into a purely serverless model.
4. Monitor differently. Serverless requires different monitoring approaches than traditional infrastructure.

Most importantly, we've gained deep empathy for our customers. By pushing serverless to its limits in our own systems, we better understand both its strengths and challenges.

Conclusion

Building Proxylity has been a journey of enabling serverless in places it hasn't been before. We're proud to run servers so our customers don't have to, while applying serverless principles throughout our own infrastructure wherever possible.

As we continue to evolve our platform, we're excited to push the boundaries of what's possible with serverless architectures and share our learnings with the community.