Михаил Р.

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

Соответственно, вам нужен новый блок в двух случаях: либо он переиспользуется, либо для разделения кода для простоты восприятия.

Возьмём разметку посложнее (не надо в ней искать какого-то смысла, просто от фонаря что-то набрал для иллюстрации):

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

Вики по GOPATH.
GOPATH подход устарел и с 1.16 версии по умолчанию используются модули.

Если вам так нужен проект в GOPATH, то можно отключить модули:
GO111MODULE=off go get github.com/go-chi/chi/v2

В режиме модулей зависимости сохраняются в кэше.
Их можно перенести в проект командой go mod vendor, и зависимости перенесутся в папку vendor рядом с файлом go.mod.

При сборке проекта зависимости автоматически скачиваются в кэш.

В подобных случаях лучше переустановить ОС к чертям, имхо.

исходя из вышеизложенного, какой бы стек технологий вы бы выбрали как разработчик чтобы решить вышеописанную задачу?

Для начала немного контекста - 2 важных примечания:
1) Описанная задача решается на любом упомянутом стеке, + еще десяток возможных вариантов (Java/Spring, питон, нода, дотнет, голанг и т.д.).
2) Быстродействие системы зависит от ее самой медленной части, и в 95% случаев самая медленная часть - БД, просто в силу специфики работы: много данных со сложными связями, выборки с сортировкой и фильтрацией из большого массива и вот это все, в то время как язык бэкенда в основном выполняет достаточно простые манипуляции с уже готовыми наборами данных (за редчайшими исключениями, которых в вашем кейсе нет, или они не описаны в вопросе).

В вашем случае:
- база можно сказать совсем небольшая, до 1 миллиона записей условный мускуль ворочает весьма шустро, если железо соответствует.
- задача сбора метрик достаточно тривиальная, особого ума в сохранении действий пользователя не надо, бОльшая часть работы - вывод в красивые графики и написание быстрых запросов с хитрыми выборками/агрегациями, немного пошаманить с формулами, возможно делать какие-то сводные выборки с денормализованными результатами для отчетов и прочие мелочи. Работа не сложная, но нудная, и ее много.

Насчет стоимости и условий:

полный самопис 150к+ (я это не тяну) или же сайт на Laravel +MySQL а дальше варьируется.

полный самопис - либо маркетинг, либо идиотизм, писать на голом языке не будет ни одна нормальная студия, в принципе в данном случае либо используется фреймворк и заказчику преподносится как "сделано вручную программистами девственниками под светом серебряной луны", либо разработчики идиоты, мнящие себя круче всех (нет). В первом случае это то же что и "сайт на Laravel +MySQL" (норма и стандарт для среднего уровня студий), во втором - развод на мани на пустом месте и попытка продать г**но в обертке "иксклюзивнасти".

По цене - на сегодняшний день, если я не ошибаюсь, 150к деревянных это +- 1000уе. Цена приемлемая за нормальную работу, если найдете дешевле "на Laravel" - думаю будет вообще ок. Опять же, цены штука такая, кто-то за копейки сделает хорошо, кто-то за дорого каку сляпает. Влияет так же регион, понятно что в Мск цена будет серьезно больше чем в условном Челябинске...

Важный момент - нормальное ТЗ в разы упрощает как поиск исполнителя, так и оценку работы. Я бы на вашем месте погрузился именно в тему создания качественного ТЗ, нежели в дебри современных технологий.

UPD:

проект планируется на 100 к+ посетителей в месяц...
предупреждают что если аудитория достигнет условных 100 тысяч в месяц Лара начнет потихонечку задыхаться от нагрузки,

ок, пусть будет 200к для наглядности.
В среднем, если это маркетплейс, то постоянных посетителей будет не много, думаю около 10%, так что ими можно пренебречь. Условно - 200к / 30 дней = 6600 в сутки, при активных 10-12 часах посещения это ~600 в час. Пусть на 1 посетителя будет 5 запросов страниц, это 600*5=3000 в час = 50 в минуту или менее 1 запроса в секунду.
Даже если умножить это на 30 (допустим такая пиковая нагрузка), 30rps вообще "ниачем". Не знаю кто там вам считал то это проблема, любое современное железо среднего уровня вытягивает без напряга.

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

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

Это не ошибка. Открой ЛЮБОЙ туториал по го, будь добр

func (h *Human) Speak() {

}

Если глянуть на внутренности языка, то метод это по сути обычная функция, у которой первым параметром является ресивер (тот объект, у которого вызывается метод). То есть, компилятор этот код превратит в

func Speak(h *Human) {

}

Соответственно, при вызове метода в случае *Human будет передача структуры по указателю, а в случае Human, по значению, со всеми вытекающими.

Что касается ошибки про несоответствие интерфейсу, то тут надо учесть, что если у структуры определены методы через указатель, то и соответствовать интерфейсу будет указатель на эту структуру: https://go.dev/play/p/o7EsGmeYSRS
Если же без указателя, то соответствовать интерфейсу будет сама структура: https://go.dev/play/p/oTsXP4DXaMJ
Но оба одновременно определить не получится.