Паттерн Outbox: как не растерять сообщения в микросервисной архитектуре

Так здесь просто проблема, которую решает этот паттерн перевернута с ног на голову. Не плохо было бы обратиться к первоисточнику где указано, что на самом деле решает этот паттерн:

How to reliably/atomically update the database and send messages/events?

И откровенно странно выглядит один из минусов — необходимость наличия базы.

А самая интересная тема, как доставить сообщения до брокера — не раскрыта. Ни чего не сказано про механизм CDC (Capture Data Change)

Эргономика решает: классные эргономические клавиатуры, на которые стоит обратить внимание

А где можно этот noname кожзам приобрести? Или это продаётся как отдельная деталь и переклеивать не надо?

Клавиатура всем устраивает и на ближайший аналог из-за этих F-клавиш не хочется переходить

Интеграционный слой с Kafka и микросервисами: опыт построения операционной CRM контакт-центра торговой сети Пятерочка

А можно пример «приоритизации сообщений», чтобы было лучше понятно о чем речь? Почему было не объединить эти два топика в один и не выбрать ключ сообщений таким образом чтобы обрабатывать их в правильном порядке?

Пост хвастовства домашними офисами

кто же так резину то хранит… надо вертикально

Сбор контекстной информации для логирования

А в пером примере не будет разве для каждой созданной задачи свой AsyncLocal.Value? Вот такой пример

static AsyncLocal<long> asyncCounter = new AsyncLocal<long>();

static void Main(string[] args)
{
    Task[] tasks = Enumerable.Range(1, 10).Select(i => Task.Factory.StartNew(() =>
    {
        asyncCounter.Value++;
    })).ToArray();

    Task.WhenAll(tasks).GetAwaiter().GetResult();

    Console.WriteLine(asyncCounter.Value);
}

ожидаем выведет на консоль 0

Сбор контекстной информации для логирования

Если речь про одновременные запросы в разных потоках, то они будут запущены все равно в рамках разных задач (Task) и контекст синхронизации будет разный и у каждой задачи опять будет свой AsyncLocal.Value.
Инстанст ConcurrentBag он свой на каждый запрос, а внутри async/await не может быть одновременно несколько рабочих потоков, которые будут конкурировать за ConcurrentBag. Даже если после await продолжение задачи (Task) попадет на другой поток из пула, она будет выполнена последовательно относительно других задач.

Сбор контекстной информации для логирования

А какой смысл там в lock'ах и ConcurrentBag'е? Если используется только async/await и потоки не создаются «руками», то как раз AsyncLocal.Value исключает конкурентный доступ в рамках одной цепочки задач (Task'ов).