По каким признакам вы определяете, что код является поддерживаемым и масштабируемым?

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

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

Как понять, что код поддерживаемый? Да вот, смотри:

• Читается как книга, а не как шифровка из штаба. Имена переменных — userService, а не us или, упаси боже, tmp. Функции делают что-то одно, а не пытаются спасти мир, решить квадратное уравнение и отправить письмо твоей бабушке. gofmt — это святое, без вариантов.
• SOLID, особенно два главных героя:
  • SRP (Принцип одной ответственности). Каждый модуль, каждая структура, каждая функция — знает своё место и делает свою работу. Не лезет в чужую. Это как на кухне: повар готовит, мойщик моет. А не так, что повар ещё и посуду за всеми собирает, блядь.
  • DIP (Принцип инверсии зависимостей). Это вообще магия. Ты пишешь код не для конкретной базы данных или внешнего сервиса, а для абстракции — для интерфейса. А потом подсовываешь туда что угодно: PostgreSQL для прода, мок для тестов, а завтра — вообще космическую базу данных с Альфа Центавры. И ничего не ломается. Красота, ёпта.
• Тесты. Если код нельзя нормально потестить — это уже подозрительно. Значит, он наверняка весь переплетён и завязан сам на себя, как удав на костыли.
• Ошибки. Их не глотают, как мартышлюшки какие-то. Их обрабатывают, логируют, возвращают наверх. Чтобы когда всё ебнулось, можно было понять, где именно и почему.
• Минимализм. Нету там лишних наворотов, мёртвого кода, который все боятся удалить, и прочей хуйни. Всё по делу.

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

• Низкое зацепление, высокая связность. Модули живут сами по себе, как хорошие соседи. Не лезут друг к другу в холодильник без спросу (low coupling), но внутри у каждого порядок и всё на своих местах (high cohesion). Хочешь переделать кухню у одного — переделывай, другим от этого ни жарко ни холодно.
• Stateless, ёбаный в рот! Это священная корова для бэкенда. Сервис не должен помнить состояние клиента между запросами. Запомнил — привязался. А как ты его тогда масштабировать будешь? Новые инстансы добавлять? Они ж этого состояния не знают! Всё состояние — в БД, в кэше, в сессионном хранилище. А сервисы — безмозглые, блядь, рабочие лошадки, которые берут задачу, делают и забывают.
• Асинхронность. Долгая операция? Не надо её делать в том же потоке, где обрабатывается HTTP-запрос. Запустил в отдельной горутине, отправил задачу в RabbitMQ или Kafka — и сразу ответил клиенту: «Принято, братан, делаем». Иначе все будут ждать, как дураки, а RPS упадёт ниже плинтуса.
• Бутылочные горлышки. Их надо искать и давить. Медленный запрос к БД на каждый чих? Кэшируй, ёпта. Синхронный вызов к тормозному внешнему API? Выноси в очередь. Иначе в один прекрасный день всё просто накроется медным тазом.

Вот, смотри, пример кода, который закладывает фундамент и для того, и для другого. DIP и SRP в действии:

// UserRepository - это абстракция (интерфейс)
// Мы не зависим от конкретной реализации (PostgreSQL, Mocks, etc.)
type UserRepository interface {
    FindByID(id int) (*User, error)
}

// UserService решает одну задачу - бизнес-логика пользователя (SRP)
// и зависит от интерфейса, а не от реализации (DIP)
type UserService struct {
    repo UserRepository
}

func (s *UserService) GetUser(id int) (*User, error) {
    // ... какая-то бизнес-логика ...
    return s.repo.FindByID(id)
}

Видишь? UserService вообще не знает, с какой базой он работает. Ему подсунули интерфейс — он и работает. Сегодня это Postgres, завтра — мок для тестов, послезавтра — какая-нибудь хрень из облака. Сервису похуй. Он своё дело знает. Вот это и есть залог спокойной жизни и масштабирования без нервотрёпки. А если ещё и тесты написать — вообще красота, можно спать спокойно.