Webinars

The concept of a Customer is often more complex than a single entity.

Really? Are you sure? Is that your final answer?

Learn how to use Azure and NServiceBus to handle unexpected peak loads and avoid embarrassment.

Are your optimization techniques really boosting system performance? It’s time to make sure with benchmarking!

Watch the Virtual DDD session and learn more about managing complexity with orchestration and choreography.

“Every microservice needs to be independently deployable.”
Let’s verify if this is true and if we can bend or break the rules during deployment.

See how modern patterns can make distributed systems more robust, scalable, and genuinely fun to build.

See Udi Dahan answer questions about system architecture, design concepts, and more in a live Q&A session.

Unavoidable failures don’t have to be a problem. With self-healing systems, they can be business as usual.

Say hello to scheduled message delivery and goodbye to middle-of-the-night alerts when batch jobs fail.

Learn how to avoid closure allocations, use memory pooling, and other tricks to make your system faster than ever before.

Observing a distributed system from end-to-end sometimes feels impossible. OpenTelemetry makes it easy.

Watch me extend the NServiceBus system from the previous webinar, adding features you’ll need to run a real-world system in production.

Join Neel Shah and Mauro Servienti for war stories about the challenges of building real-world distributed systems.

Distributed Systems Design Fundamentals course questions answered live

Watch me build an NServiceBus messaging system during this live coding session, mistakes and all.

“Have all my overdue invoices been paid?” Seems a simple enough question. But once you factor in the effects of time, even the simplest question can turn into a mess of edge cases and complicated batch jobs that never quite complete on time.

The NServiceBus Outbox gives you consistency between database and messaging operations, something that would be nontrivial to do on your own. So how does it work? And how can you prove that it works?

Azure Service Bus is a complex and powerful tool. Get a guided tour of the .NET SDK from an Azure MVP.

So serverless is the new hotness, right? But are Azure Functions right for your system? What about the on-premises code you already have? What can you do now to make it easier to move to the cloud? If these questions sound familiar, this is the webinar for you.

The patterns of Domain-Driven Design were originally introduced when line-of-business systems were still predominantly monolithic. That is not the case anymore. Modern-day designs are not only distributed but also require a wide array of data stores - each specialized in storing different types of data.

In the last few years, there’s been a shift from deploying applications on premises to deploying them in the cloud using services such as Azure and AWS. However, with so many options to choose from, it can be difficult to know what the trade-offs are.

Azure Cosmos DB provides highly reliable, scalable, and performant data storage in the Microsoft Azure cloud. However, designing your NServiceBus system with Cosmos DB to create performant, reliable, and transactionally consistent business processes in a multi-tenant environment requires careful design.

At a basic level, you have eventual consistency when you read data that has been updated, but you can’t see that yet. In distributed systems, eventual consistency is inevitable. But how do you deal with eventual consistency in your system? How can you make it work?

Do you want to find out from your log files that you missed out on a million-dollar order? Then you need to understand how message deduplication works and how to apply it successfully.

This is a great opportunity to address questions relating to system architecture, design concepts, and more - in a live question and answer session with Udi.

You’ve decided to develop in Azure and now need to pick a messaging technology. You have multiple options: Storage Queues, Service Bus, Event Grid, Event Hubs, etc.

Business requirements are seldom as simple as they seem. What happens when the requirements start to get more complex than your original design? Will you be able to adapt?

We know it’s useful to split up complex systems. We’ve seen the benefits of modular deployment of microservices. Dealing with only one piece of code at a time eases our cognitive load.

But how do we know where to draw the service boundaries?

Monoliths are hard work. They’re difficult to understand, brittle to change, time-consuming to test and risky to deploy. And you’re stuck with the monolith’s tech stack so you can’t use any modern architectures or technologies. Decomposing monoliths is easy if you take the right approach, and it results in a distributed solution with many small components. Those can be independently updated, tested and deployed, which means you release better software, more quickly.

Building a reliable message pump that consumes and produces messages from queues is simple, in theory. In practice however, the picture looks a bit different. As contributor for queue adapters for RabbitMQ, Azure Service Bus, Azure Storage Queues, MSMQ, AmazonSQS, Kafka and SQL Server, Daniel Marbach says he has made plenty of mistakes along the way. Now you don’t have to.

Daniel Marbach, solution architect at Particular Software, shows how to leverage reliable messaging through NServiceBus in your Service Fabric services while still using Reliable Collections.

Learn to design systems that are easily understood throughout your company, and supercharge the resolution of production issues.

Matt Snider, PM on Service Fabric, gives a comprehensive overview and tells of plans for its future.

William Brander and Sean Farmar show how the monitoring game changes when a system becomes distributed and you start delving into the world of microservices.

Yves Goeleven and Sean Feldman show how to use NServiceBus and the Azure Service Bus transport to leverage established patterns and best practices so that you can focus on your business logic.

Yves Goeleven and Sean Feldman show how to remove the pain of setting up secure communications across network boundaries with Azure Service Bus.

Microservices is all the rage, but how do I avoid the pitfalls associated with microservice development?

Mauro Servienti and Sean Feldman show how to connect an asynchronous back end to the front end.

Daniel Marbach shows how the NServiceBus v6 API update helps to avoid common Async/Await pitfalls and makes your code ready for asynchronous APIs in the cloud.

Daniel Marbach shows how to combine Async/Await and Task Parallel Library to create a message pump for a service bus.

Daniel Marbach shows how to avoid common pitfalls in asynchronous code bases.

Andrea Saltarello shows how to evolve systems architecture leveraging CQRS principles and NServiceBus Sagas.

Mauro Servienti and Sean Farmar show how to use messaging architecture and unique features in NServiceBus to power a web application with real-time request-response and publish-subscribe messaging.

Mauro Servienti and Daniel Marbach show how NServiceBus simplifies infrastructure code written to handle different failure types, and how tools like ServiceInsight and ServicePulse simplify system monitoring and failure recovery.

Elton Stoneman shows how to use messaging architecture to power a web application with real-time request-response and publish-subscribe messaging.

Elton Stoneman (consultant, author and Microsoft MVP for systems integration) covers various failure types and recovery strategies in message-driven systems.

Daniel Marbach and Mauro Servienti expand on part 1 in the messaging series, which showed how to build scalable systems on top of bare messaging with queues, by demonstrating how NServiceBus makes the entire process easy, enabling you to focus on business logic, without forcing you to write a lot of infrastructure code.

Elton Stoneman (consultant, author and Microsoft MVP for systems integration), gives insights into scaling with messages and queuing technologies.