Никита Гусев

Использовать ли асинхронность и отправлять ли файлы параллельно - это два разных вопроса. Асинхронность имеет смысл, если вы не хотите блочить основной поток в клиентских приложениях, или хотите экономить потоки в серверных приложениях.
Параллельная отправка файлов скорее всего смысла не имеет, вы будете всё равно упираться либо в сеть, либо в диск. Больше и смысла в том, чтобы увеличить размер буфера, или сжать файлы в архив перед отправкой.

И то и другое архитектурные концепции, и их значение может от контекста зависеть.
Например в ddd главное отличие - сущность имеет идентификатор. То есть работая с доменным объектом Order, вы работаете с конкретным заказом, а не со всеми заказами сразу.
Если вы инстанцируете класс order, и можете работать из него с любым заказом - это скорее сервис.
По крайне мере в ddd сущность описывается именно через identity. Можете почитать книгу Эрика Эванса или Вона Вернона (главы где рассказывается, что такое entity).

можно сделать более оптимизированно, если не аллоцировать для полей новые строки, а использовать IReadOnlySpan. Вот минимальный пример:

var input = "John Stockman|+17651233243";
var record = new Record(input);

Console.WriteLine($"Name: {record.Name} Phone: {record.Phone}");

class Record
{
    private string line;
    private int delimeterIndex;
    public Record(string line)
    {
        this.line = line;
        delimeterIndex = line.IndexOf('|');
    }
    public ReadOnlySpan<char> Name => line.AsSpan(0, delimeterIndex);
    public ReadOnlySpan<char> Phone => line.AsSpan(delimeterIndex + 1, line.Length - 1 - delimeterIndex);
    public override string ToString() => line;
}

Берите готовое, сами замучаетесь это писать. Из OpenSource можно взять jitsi, есть дефолтный интерфейс, можно интегрировать с любым клиентским приложением (android, ios, web). Можно работать peer-to-peer, может через сервер (чтобы транслирующий не гонял сразу 12 видеопотоков).
На чем бэкенд писать действительно не принциально, главное знать, как интегрироваться с jitsi.

Ну обычно есть скрам-мастер, который пояснит тебе за ценности компании и скажет, что надо постараться всё переделать. А дальше ты будешь проявлять креативность, как на костылях и велосипедах это побыстрее переписать и забудешь про архитектуру и прочие глупости.

можно воспользоваться утилитой ffmpeg, она поддерживает отправку данных стриминговым сервисам. Использовать в C# можно либо через библиотеки, либо просто через консоль.
Судя по интернетам, конкретно с IceCast ffmpeg не очень хорошо работает, поэтому в этом случае лучше другой сервис выбрать (gstreamer, ffserver и т.д.).

Зависит от того, какого рода "общение" происходит между сервисами.
Для получения данных от других сервисов логично использовать REST.
Если мы говорим о публикации событий, то логично использовать очереди (например, нужно пересчитать агрегаты при обновлении данных).
Если мы говорим про распределенные транзакции, то тут очереди и саги (архитектурный шаблон). Нужен отдельный сервис, который будет координировать шаги транзакций, обрабатывать отказы и т.д.. Советую посмотреть на такой проект для .NET, как MassTransit.
Также стоит продумать над вопросом логирования и трассировки, чтобы можно было получить все логи конкретного пользовательского запроса со всех микросервисов.