Skip to content
Hallway
0:00 / 0:00

#distributedsystems#outboxpattern#masstransit

Six Little Lines of Fail - Jimmy Bogard

NDC Conferences

230K subscribers • 110 videos on Hallway • Conference channel

YouTube
  • Recommended by 5 people: 1 on Lobsters and 4 in engineering communities.
  • A classic. People kept recommending it from 2020 to 2024.
  • Presented by Jimmy Bogard, creator of MediatR and AutoMapper

Intermediate. Assumes working knowledge.

85K views7 years ago5 recommendations

Distributed systemsSoftware designConcurrency and parallelismFault tolerance and failureSoftware architecture

Jimmy Bogard analyzes how a seemingly simple checkout flow can fail in a distributed system and explores patterns to ensure correctness.

It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code! Finally we can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code. But those lines hid a dark secret that we only found after launching. Customers complained they didn't get their email. The back end system wasn't getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged! Clearly it wasn't as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we'll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We'll also look at the coupling our code contains, and the ways we can address it. Finally, we'll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing. NDC Conferences ndcconferences.com ndcporto.com

Why it's here

5 people recommend this

What people say. Highly recommended as an excellent explanation of failure scenarios in distributed systems and how to handle them reliably.

u/broken-neuronsin r/dotnet • Recommends

On “'Don't use a database as a queue'”

Depends on which of those things can be dealt with in a transaction. If you need to use multiple database contexts, and call an API and then send an email, you can’t roll those things back. Oldie but good explanation: link to this video
7View on Reddit

u/super-jurain r/dotnet • Recommends

On “In the case of building a system where we need to use pub/sub pattern (e.g. e-commerce), should we use MassTransit if we are building a monolithic app?”

Everything depends on the case you need to cover. Jim Bogard made nice video about this link to this video
7View on Reddit

friendlysockon Lobsters • Recommends

Six Little Lines of Fail
5View on Lobsters

u/broken-neuronsin r/dotnet • Recommends

On “API Retry Policy for a hierarchy of requests”

First watch this: link to this video Then check this out: https://masstransit.io/documentation/patterns/routing-slip Doing much the same thing as you. Think of using Polly only as a retry around individual transient HTTP exceptions and message retries wrapped around the larger context.
2View on Reddit

u/pdevito3in r/dotnet • Recommends

On “# Choosing Between using Clean/Onion or Vertical Slice Architecture for Enterprise Apps in .NET”

> or bigger like folder: Product: - Add.cs - Delete.cs No this would be two features. The size of the feature would depend on the feature itself. For example, say you need to check the database before you add a product to make sure you’re not adding a duplicate one. A larger feature could be a `processpayment` feature like this.
1View on Reddit

u/broken-neuronsin r/dotnet • Recommends

On “Proxy a bulk request to a none bulk endpoint in ASP.Net”

It depends on how resilient this request needs to be. If you can risk it failing now and then because one of the aggregated requests fail, then fire off the three in sequence or in parallel and aggregate. Three aggregated GET requests for example, when one fails it’s not the end of the world, and you reflect the transient error back to the client and they try again, but if any of them are write actions, you’ll really need to treat them in a resilient manner and orchestration and message queues are the one tried and tested way of doing it. You didn’t indicate whether any of those proxies calls result in a write action. If you are, I suggest you watch link to this video
1View on Reddit

u/codeonlinein r/dotnet • Recommends

On “Transactional Outbox Pattern: Handling Failures Where an Event Has Multiple Handlers”

…t explains the various failure scenarios around something like this and how to handle possible failures at each line. ```cs GetCustomer() AddItemToOrder SaveCustomer(); BillViaStripe(); (stripe goes down, now what?) SendConfirmationEmail(); (email is unavaiable, now what?) AddToNewsletter(); (whoops third party has rate limited us, now what? ``` link to this video…
1View on Reddit

u/codeonlinein r/dotnet • Recommends

On “Transactional Outbox Pattern With Multiple DDD Sub-Domains”

This is a good watch.. Its not so much about scale or complexity. Its about correctness and being able to anticipate failures and ensure your application and its data remains in a valid state despite failures at each or any step of a process. link to this video
1View on Reddit

u/peterknealein r/dotnet • Mentions

On “Heard of the Transactional Outbox pattern but unsure of the problem it solves?”

There is a good video here describing the scenario  link to this video
1View on Reddit

u/broken-neuronsin r/dotnet • Mentions

On “Multi tenancy”

What happens if the REST request fails? My favorite talk about this topic is this one Six little lines of fail
1View on Reddit