DollyPapper

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

Оттого и вопрос - можно ли обойтись без всего этого, сохранив плюсы реализации транзакционных механизмов РСУБД на микросервисах?

Паттерны распред. транзакций от того и появились, что нельзя. У вас физически несколько разных БД на разных хостах. Транзакция это свойство систем хранения данных, когда мы атомарно фиксируем некоторое состояние системы в БД. В распределенной системе - в нескольких БД. Сайд эффекты типа отправки СМС не имеют никакого отношения к транзакциям. Либо отправляйте СМС после полной фиксации транзакции, либо как вариант используйте компенсирующую СМС, типа - "Извините мы ошиблись на самом деле мы не сделали того о чем мы писали в прошлой смс", но это уже в порядке бреда.

Грубо говоря докер это изолированный от системы некий процесс. Можно считать это некий chroot для процесса.
Представьте себе операционную систему в которой есть некоторое пространство из ресурсов. Память, диск, системное время, сеть, сетевые интерфейсы. И в этом пространстве находятся процессы которые используют эти ресурсы. А теперь представьте что в этой большой системе мы откусили кусок ресурсов и некоторый процесс, например БД изолировали от всей остальной системы. Докер это своеобразная матрица (всмысле как в фильме матрица) для процесса некоторого.

Что такое глоаблаьные объекты и как они работают?

Глобальные обьекты это обьекты обьявленные в глобальной области видимости в программе и доступны из любого места программы.

И что-ли все переменные это прсотос свойства?

Нет. Переменные это переменные, свойства это свойства.
let a = {f: 10}
a это переменная, f это свойство обьекта.

И я почитал про создание перменной без исопльзования клчевых слов let/var/const.

Это круто, держите нас в курсе.

Какая вся картина ооп

Большая и противоречивая. Конкретней задавайте вопрос.

У вас какая-то странная логика получилась.

_, err := db.Query("SELECT chat_id FROM telegram WHERE chat_id=?", chatID)

если этот запрос отработает без ошибок (в т.ч. если результат будет не пустой), то err будет = nil, следовательно выполнится блок else и создастся пользователь. Т.е. буквально, если уже есть такой пользователь, то вы создаете нового.
Вам нужно что-то типа

_, err := db.Query("SELECT chat_id FROM telegram WHERE chat_id=?", chatID)
if errors.Is(err, sql.ErrNoRows) {
// создаем пользователя
} else {
fmt.Println("Пользователь уже есть в базе данных")
}

Во первых аутентификацию. Авторизация это про проверку прав.
Если без REST API, то классика это принимать через POST запрос данные с формы.
Вот статья
Если кратко:
Делаете ручку /signin, которая проверяет пароль присланный пользователем с хешем паролей в базе данных (ну или где вы храните данные)
Если всё ок, создаете сессию, сохраняете сессию где нибудь в хранилище (опять же это может быть база данных, может быть ин мемори, есть библиотеки для этого, погуглите, да хоть в памяти приложения в мапе храните)
Далее ID сессии записываете в куки и посылаете ответ пользователю в заголовком Set-Cookie sessid="session_id", где session_id это айди который вы раньше сгенерили.
А далее пользователь ходит на ваш сайт, и какая нибудь мидлвара берет из запроса куки, берете оттуда id сессии, ищет этот айди в хранилище. Если нашла, то пропускает запрос дальше, если нет - 401 Unauthorized.
Ну в статье вобщем всё подробно описано.

Спорный вопрос. Смотря что мы с данными хотим делать и как часто. Есть возьмем к примеру базы данных, и массив и захотим поискать данные, то вероятно файл (бд) окажется даже выгодней, поскольку поиск в массиве будет занимать O(n) а поиск на диске O(logn) при условии что ищем мы по индексу

Про репозиторий можно почитать например тут

Если вы будете пул создавать каждый раз при запросе в каждой функции, то какой тогда смысл от пула? Пул в go это своего рода синглтон, он создается один раз и далее распространяется по всему приложению. Очевидно, что если каждый раз будет новый инстанс пула, то никакой защиты от переполнения коннектов мы не получим. Итого: пул создается один раз, далее во всех остальные части программы он передается как вам удобно, через DI напрямую в фукнцию, в конструктор обьекта или еще как.

Смысл делать поля экспортируемыми есть в очень редких случаях. Один из таких случаев например маршалинг (json/yaml/etc), без экспортируемых полей библиотека просто не сможет засеттить значение в поле. Другие дело обстоит с сущностями (обьектами/структурами вашей предметной области). В случае сущности эта самая сущность должна скрывать свое внутренее состояние и не позволять изменять его извне. Приведу банальный пример:

type User struct {
    Name string
    Age    int
}

И сеттеры геттеры к ней.

Далее допустим есть бизнес правило, что у вас можно регистрировать пользователей строго старше 18 лет. Как вы будете контролировать, что нельзя назначить возраст < 18 лет? Да никак, с экспортируемыми полями это невозможно. Почитать на эту тему можно погуглив про инкапсуляцию и information hiding. В данном конкретном случае геттеры и сеттеры наверное будут более подходящими. В сеттерах можно прописать условие, что возраст должен быть строго больше 18 лет. Однако может быть и такой случай, что сущность не должна вообще более изменяться после создания. Для этого в ООП языках, чтобы задать первоначальные значения существуют конструкторы. В го нет конструкторов, т.к. нет понятия класса, но нам ни что не мешает создать обычную функцию порождающую обьект юзера, и засеттить значения возраста и имени в этой фкнции.

При классовом подходе у вас есть класс и его экземпляр. Состав полей и цепочка наследования при этом задана жестко во время написания. В прототипной модели у вас нет классов, есть обьекты прототипы которые могут динамически мутировать по ходу выполнения программы. Мутация означает, что мы можем изменять не только значения атрибутов обьекта, но и сам состав этих атрибутов.

Возможно уже неактуально, но.
Не следует строго следовать мантрам про "глобальные переменные это плохо". Иногда это необходимо. Делаете из своего кеша синглтон (как его правильно делать в го можно посмотреть в инете). Переменная инстанс самого обьекта кэша будет лежать на уровне пакета кэша и будет неэкспортируемой. А сама New будет возвращать либо кэш, если он уже ранее был создан, либо тот инстанс который был создан. Так например pgxpool устроен ЕМНИП.

Ну отвечу баяном - для начала учимся гуглить и гуглим свой же вопрос. Если твой вопрос в поиске на данном сайте ввести, то найдется овер дофига ответов...

В целом да, всё норм

А в каком предложении своего вопроса вы собственно описали концепцию? Вы описали некоторые свойства брокеров. Основная концепция брокеров это быть звеном передающим сообщения в распределенном окружении. Это не обязательно микросервисы, это могут быть вполне себе монолиты.

а преимущество в основном то, что все сообщения проходят через одно место и тебе не надо париться, чтобы сервисы знали на каком порту они развёрнуты чтобы передавать сообщения напрямую друг другу

Вместо того чтобы сервисы знали друг о друге они будут должны знать где находится брокер. Шило на мыло.
Основное преимущество в том, что брокер гарантирует доставку.

Т.е. в резюме у вас будет NDА, а в трудовой название компании? Што?
Мне прям интересно, что это за компания которая не хочет чтобы ее в резюме упоминали. Гидра какая нибудь :)

Вы перепутали связи и ограничения в БД. Неформально связи как раз и закрепляются ограничениями типа внешний ключ, но в целом связи это вопрос формализации моделируемого мира в контексте вашей БД. У вас уже есть связь между сообщинем и пользователем. Тот факт что у вас в сообщении имеется колонка userid как раз и есть факт связи, что две сущности: сообщения и пользователи связаны. Однако эти связи принято подкреплять на уровне самой БД теми самыми огланичениями. как указал mayton2019 я могу в вашей системе в теории создать сообщение которое не принадлежит ни одному пользователю в вашей базе. Рассматривайте ограничения как штуки которые не позволяют нарушить логику ваших связей.
Еще почитать на тему проектирования связей