Q&A

Cracking the Code of Serverless Design: Patterns that Scale and Patterns that Fail

• By David Ramel
• 02/23/2026

Serverless computing has matured well beyond its early promise of "just write code and let the cloud handle the rest." Today, platforms like Azure Functions, AWS Lambda and their surrounding ecosystems are powerful, production-ready tools--but only when they're used with the right architectural mindset. Too often, teams approach serverless as a tactical add-on rather than a distinct architectural style, leading to systems that are brittle, overly complex or unexpectedly expensive.

That gap between potential and practice is the focus of "Crack the Code of Serverless Design", an intermediate-level session at Visual Studio Live! Las Vegas coming in March, presented by Chad Green, a senior systems architect at Jasper Engines & Transmissions. Drawing on nearly a decade of hands-on experience with serverless technologies, Chad will walk attendees through the design patterns that underpin successful serverless applications--and just as importantly, the common missteps that cause them to falter.

Rather than treating patterns as abstract diagrams, the session emphasizes live, working demonstrations that show how serverless patterns behave under real conditions. Attendees will see how event-driven and orchestrated approaches differ in practice, how asynchronous workflows succeed or fail depending on retry and error-handling strategies, and why state management remains one of the most misunderstood aspects of serverless design. Chad also addresses practical concerns developers encounter after deployment, including scaling behavior and the cost surprises that can arise from patterns like fan-out or from consumption-based pricing models.

The goal of the session is not to promote a single "correct” architecture, but to help developers and architects build better intuition around when serverless excels, when it requires extra care, and how proven patterns can turn promising ideas into resilient, scalable cloud solutions. In this Q&A, Chad discusses what first drew him to serverless computing, the patterns he sees most often misused in the wild, and the lessons he hopes attendees will take back to their own projects.

VisualStudioMagazine: What inspired you to present on this topic?
Chad: I first discovered Azure Functions in 2016, just weeks after they were released. At the time, I wasn't looking for "serverless"; I was simply trying to solve a real problem at work. Azure Functions turned out to be the perfect fit, and that experience completely changed how I thought about building systems. I was immediately drawn to the serverless computing paradigm and have been building serverless-based solutions ever since. Today, it's one of the first architectural approaches I consider when starting a new project.

Over the years, though, I've seen a recurring pattern: teams struggle with serverless not because the technology falls short, but because it's misunderstood. I've heard many stories of "failed" serverless projects, and when you dig into them, the issue is rarely the platform itself. More often, serverless was treated as a feature you sprinkle into an existing design, rather than an architectural style that requires intentional patterns.

This session is driven by that gap. Serverless truly shines when the right design patterns are applied, and it can fall apart just as quickly when they aren't. My goal is to help developers and architects understand what serverless is well-suited to, where it requires careful design, and how proven patterns can turn a promising idea into a resilient, scalable solution.

What's one serverless pattern that developers often misuse or overcomplicate in real-world projects?
Orchestration is one of the most commonly overused patterns in serverless systems. The tooling is powerful and elegant, but that's also what makes it easy to violate the "keep it simple" principle.

When I joined my current company, many of the teams were new to cloud computing, serverless, and event-driven architectures. I introduced them to Durable Azure Functions, and the reaction was immediate. They were amazed by what orchestration made possible. We ran workshops, built labs, and the teams quickly became comfortable with the model.

The challenge came later. Orchestration became the default solution. Every new requirement was framed as a workflow, even when a simpler, more event-driven approach would have been clearer, more resilient, and easier to evolve. The result wasn't broken systems; it was unnecessary complexity.

Orchestration is absolutely the right tool in certain scenarios, but serverless architectures tend to shine brightest when they remain loosely coupled and intentionally simple. One of the key themes in this session is learning when orchestration adds value and when it quietly works against you.

Can you give a quick example of how you handle error retries in an asynchronous serverless workflow?
In an asynchronous serverless workflow, retries need to be deliberate, not automatic. The first step is clearly documenting what should be retried and what should not. If a failure is caused by invalid data or a business rule violation, retrying won't help; you're just trying to force a square peg into a round hole. Those failures should be treated as terminal and routed elsewhere for inspection or correction.

For retryable failures, timing matters. Computers work incredibly fast, and immediately retrying a failed operation usually just guarantees another failure. Introducing delay and backoff is critical, especially when downstream systems are degraded or temporarily unavailable.

One of the most frustrating things during an outage is having a system repeatedly hammer the very service you're trying to recover. It's like a kid in the back seat constantly asking, "Are we there yet?" Thoughtful retry policies, such as bounded attempts, increasing delays, and clear failure paths, help systems recover gracefully rather than making bad situations worse.

How do you recommend managing state across multiple functions without breaking scalability?
You don't. State and serverless computing do not go hand in hand. To preserve scalability, state must be treated as an external concern.

This is one of the hardest concepts for people new to serverless to internalize. Traditional application design often encourages holding state in memory or tightly coupling it to execution flow. Serverless flips that model entirely. Functions are ephemeral, scale dynamically, and make no guarantees about execution order or instance reuse; any attempt to manage state inside them quickly undermines those strengths.

Instead, state should live in purpose-built external services such as databases, durable workflow stores, or messaging systems. When state is explicit and externalized, functions remain stateless, interchangeable, and scalable independently. That separation is what allows serverless systems to remain resilient under load and adaptable as requirements evolve.

Once teams embrace the idea that functions operate on state rather than own it, scalability becomes a natural outcome of the architecture rather than a concern.

What's a good rule of thumb for deciding between orchestrated vs. event-driven patterns in serverless apps?
I generally start with event driven patterns. I value the clear separation between publishers and consumers and the flexibility that model provides. Event driven designs allow systems to evolve independently, scale naturally, and adapt to new requirements without constantly reshaping a central workflow.

Orchestration has its place, but I treat it as a focused tool rather than a default. Even when I do use orchestration, it's often initiated by an event rather than a tightly coupled request. That approach preserves the benefits of loose coupling while still allowing coordination when it's genuinely needed.

A good rule of thumb is this: if the problem can be solved by reacting to events and letting components operate independently, start there. Reach for orchestration only when you truly need explicit control over sequencing, long running coordination, or compensating actions. Starting event driven keeps designs simpler and gives you more room to grow without re architecting later.

In terms of cost efficiency, which pattern tends to surprise developers with unexpected usage costs?
Fan out patterns are among the biggest sources of unexpected costs in serverless systems. They're incredibly powerful, but also very difficult to estimate accurately before implementation. A single event triggering many downstream executions can multiply usage quickly, and the more useful the system becomes, the more often that fan out tends to occur. What looks inexpensive in early testing can scale into a surprise once real traffic arrives.

Another common cost trap isn't a pattern so much as a pricing assumption. Consumption-based pricing is extremely attractive, and in many cases, it does result in much lower bills. The problem is that teams often stop thinking about cost once they see how cheap it is at low volume. There is always a point where consumption pricing becomes more expensive than provisioned or premium options.

Cosmos DB Serverless is a good example. If you're frequently querying large amounts of data, costs can climb quickly. Azure SQL triggers provide another real world case: they poll underlying lease tables every five seconds. Monitor enough tables, and that "amazingly priced" Flex Consumption plan can end up costing more than a more static Premium configuration.

The lesson is that serverless cost efficiency isn't automatic. Patterns like fan out and pricing models like consumption need to be evaluated together, with an understanding of how often things execute and how that usage grows over time.

Are there any serverless patterns that don't work well across cloud providers and need heavy adaptation?
I'm not a big believer in designing serverless systems primarily around portability. It sounds appealing, and while I do know teams that have moved from one cloud provider to another, most never do. In practice, optimizing for a hypothetical migration often leads to unnecessary abstraction and missed opportunities to leverage a platform's strengths.

That said, some serverless patterns do require heavier adaptation across providers. Durable orchestration is a good example. Azure Durable Functions and AWS Step Functions solve the same fundamental problem (long-running, stateful workflows), but they approach it in very different ways. The pattern transfers, but the implementation details don't.

Event-driven patterns tend to translate more cleanly. Concepts like publishers, consumers, and message-based decoupling exist everywhere, even if the services and tooling differ. In those cases, the architectural intent carries over more easily than the mechanics.

The takeaway is that patterns matter more than portability. If you understand why a pattern exists and what problem it solves, adapting it to another platform becomes a design exercise, not a rewrite driven by fear of lock-in.

How can attendees learn more about this topic and also prepare for your session?

Hands on experience is key. Whether it's serverless computing or anything else in software development, nothing beats fingers on the keyboard. For more than three decades, I've encouraged developers, both new and experienced, to simply build things. Even if you throw them away. Especially if you throw them away.

Serverless patterns make the most sense when you've felt how they behave; how they scale, how they fail, and how they recover. Reading about them helps, but building small, disposable experiments is where the real learning happens.

Attendees don't need to prepare extensively for this session. The live demonstrations are designed to make the patterns tangible and approachable. The goal is to leave with practical mental models and the confidence to start experimenting immediately because that's where understanding really begins.

Note: Those wishing to learn more about the range of VSLive! Las Vegas sessions covering the latest in Visual Studio, .NET 9, ASP.NET Core, Generative AI, GitHub Copilot, .NET MAUI, Azure, Blazor, C#, modern data solutions and beyond can visit VSLive! Las Vegas. "You may be eligible for an attendee or team discount, so please visit the pricing page to see if you qualify," said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.