d'Ivan

TinyMCE (WYSIWYG) изначально поддерживает HTML, но с плагином Text Pattern поддерживает разметку Markdown.

В контекст можно передать нужные пары ключ-значение с WithValue

ctx := context.Background() // исходный контекст
ctx = context.WithValue(ctx, "foo1", "bar1") // переопределенный
ctx = context.WithValue(ctx, "foo2", "bar2") // переопределенный

И это безотносительно фреймворка

Если нужна доставка одного и того же сообщения нескольким сервисам, то fanout подходит.
Если нужно разослать сообщение по разным подкатегориям по маске (скажем, регионам), то можно использовать обмен типа topic.
https://dev.to/larapulse/dealing-with-rabbitmq-exc...

пока что около 10тыс сообщений в сутки, но будет больше.

Можно взять Sphinx Search с адаптером для Postgres, где и хранить все сообщения. Или только Postgres, для простоты и лёгкого старта. Полнотекстовый поиск есть и в нём.
Или RediSearch (модуль-новинка в Redis) - но насколько я понимаю, всё будет в памяти экземпляра, что может быть дороговато со временем.
Если сильно вырастите со временем, тогда можете смотреть на ElasticSearch (осознание о необходимости придёт на некотором этапе).

Если я верно понял, вопрос о том как сделать так, чтобы можно было слушать gRPC и RabbitMQ с одного сервиса.
Тогда можно в теле main.go

app := NewApp()
app.Start()

в структуре App можно декларировать ссылки на хэндлеры соединений для gRPC, RabbitMQ.

func (a *App) Start() {
  go listenGRPC()
  go listenMQ()
}

Микросервис запустит 2 горутины, каждая из которых будет слушать и обрабатывать свои соединения независимо.

Хочется хранить весь профиль пользователя (то, что обычно называют Vaults или Spaces в похожих приложениях) включая бинарные файлы (библиотеки изображений, мультимедиа, документов и т.п. файлов) в едином файле с быстрым доступом, вместо иерархии папок на файловой системе.

Хранить в архивах ZIP, TAR/PAX, конечно, можно, но не сильно удобно: вместо работы с файлами придётся работать с библиотеками для работы с архивами: то записать в архив, то прочесть с него. С точки зрения производительности вряд ли будет столь же эффективно, как с файловой системой (даже с иерархией папок).

Можно просто держать пользовательские настройки и файлы - отдельно. И ничего особо мудрить тогда не нужно и будет очень универсально. Хотя, с точки зрения кросс-платформенности, скорее всего, будет не так всё хорошо. Но если пользоваться библиотеками поддерживающими кросс-платформенность - так лучше, конечно.

В настольных приложениях общие настройки и данные хранят в /etc , /usr/share , /usr/lib (Linux) , пользовательские - согласно спецификациям XDG и в Windows - в своих директориях.

Медиа-файлы, конечно, должны быть доступны приложению простым образом, без необходимости писать/читать в/из архив(а). Особенно, если необходимо запустить ассоциированное с типом файла внешнее приложение, как видео-проигрыватель.

Более гибкий вариант: использовать SQLite или какую-то K/V СУБД (тот же Redis!). В добавок к кросс-платформенности получаем возможность простым API работать с данными, не занимаясь мелочью типа открыть-закрыть файл, (де)сериализовать данные (настройки всякие), записать/прочесть блок данных. Ими занимается драйвер СУБД (обычно библиотека) и сама СУБД.

Дополнительный гибридный вариант - использовать файлы локально и удалённо (с SDK): допустим с каким-нибудь объектным хранилищем, по протоколу S3 или другому. Как вариант, даже, использовать драйвер VFS для прозрачной работы с неким хранилищем, которое с точки зрения настольного приложения будет работать, как обычная ФС.

Для примеров можно взять типичные приложения типа веб-браузера или какого-нибудь мессенджера и посмотреть какие технологии используются в них.

Для периодического выполнения задач можно использовать гем whenever, при помощи которого можно запускать ежедневную Rake задачу. Можно и с помощью cron, но не столь удобно, как с гемом.
Эта задача может ежедневно сверять дату и проверять в СУБД для каких пользователей нужно обновить атрибут модели (баланс или что-то другое).

Консольная программа (которая не имеет графического интерфейса как Calculator) может работать только в сеансе терминала. Для этого нужно открыть cmd или powershell.
Если запускать вне терминала (с Рабочего стола), то программа запустится и очень быстро закроется, поскольку она выполняет свою задачу и сразу завершается. Чтобы увидеть результаты работы (какой-то вывод на экран), нужно вставить действие для ожидания от пользователя, допустим getch();
И не забыть инклюды

#include <stdio.h>
#include <conio.h>

Вот предлагаемый порядок для исследования возможностей поиска:

1. Postgres: full text search
   
2. Sphinx Search или форк Manticore Search : можно также подключить к существующей СУБД.
   
3. ElasticSearch (если Sphinx не подойдёт по каким-то причинам)