Platforma handlowa przetwarza wieloetapowe przepływy pracy zamówień. Każde zamówienie generuje konwersację powiązanych wiadomości (zamówienie utworzone, płatność autoryzowana, pozycje zarezerwowane), które muszą być przetwarzane w kolejności dla każdego OrderId przez wielu subskrybentów. Gdy worker przetwarza wiadomość „zamówienie utworzone”, musi atomowo wysłać dwa polecenia do usług podrzędnych lub wycofać się, jeśli przetwarzanie się nie powiedzie. Wiadomości poison message muszą być izolowane bez ich utraty. Jaki projekt systemu przesyłania wiadomości należy polecić?

Poprawna odpowiedź to temat Azure Service Bus z włączonymi sesjami. Sesje Service Bus (sessionId=OrderId) gwarantują uporządkowane przetwarzanie wiadomości dla każdego OrderId, co jest kluczowe dla wieloetapowych przepływów pracy. Transakcje Service Bus zapewniają atomowe wysyłanie poleceń do usług podrzędnych i ukończenie wiadomości przychodzącej, co jest wymagane w przypadku niepowodzeń. Podkolejka dead-letter automatycznie izoluje wiadomości poison message bez ich utraty. Pozostałe opcje są nieodpowiednie: Kolejka Azure Service Bus bez sesji nie gwarantuje uporządkowania wiadomości dla danego OrderId. Ręczna kompensacja i niestandardowa kolejka błędów to mniej niezawodne rozwiązania niż wbudowane mechanizmy Service Bus. Kolejka Azure Storage Queue nie oferuje wbudowanych mechanizmów do gwarantowania kolejności wiadomości ani transakcyjności obejmującej wiele operacji. Wykrywanie wiadomości poison message jest mniej zaawansowane. Azure Event Grid nie gwarantuje uporządkowania wiadomości w taki sposób, jak sesje Service Bus, ani nie zapewnia transakcyjności dla operacji wysyłania i odbierania. Temat Azure Service Bus bez sesji nie zapewnia uporządkowania. Wyłączanie dead-lettering prowadzi do utraty wiadomości poison message.