Бэкенд-разработка

Go Identity Service.

Бэкенд на Go для аутентификации и управления пользователями: REST- и gRPC-интерфейсы, кэш Redis и транзакционная обработка событий. Проект для портфолио, показывающий, как связать аутентификацию, хранение данных и асинхронные процессы.

ТИП ПРОЕКТА
Самостоятельный проект для портфолио
КОМАНДА
Данил
РОЛЬ
Архитектура бэкенда, проектирование API и реализация
ТЕХНОЛОГИИ
Go / PostgreSQL / Redis
REST + gRPC
HTTP-сценарии и типизированные запросы пользователей
Transactional outbox
Изменения и события в одной транзакции
Docker + CI
Воспроизводимые сборки и автоматические проверки
Содержание кейса
01

Инженерная задача

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

02

Аутентификация с понятными границами

REST API поддерживает регистрацию, вход, обновление токенов, выход и получение текущего пользователя. Пароли хешируются через bcrypt. Refresh-токены хранятся в виде хешей и обновляются транзакционно. Ролевые проверки защищают операции с пользователями. В gRPC UserService доступны GetUser и ListUsers.

  • PostgreSQL хранит пользователей, refresh-токены, outbox и аудит.
  • Redis используется для кэша пользователей и ограничения частоты запросов.
  • OpenAPI и Protobuf описывают внешние контракты.
Посмотреть реализацию
03

Доставка событий с учётом повторов

Регистрация записывает пользователя, refresh-токен и событие UserRegistered в одной транзакции PostgreSQL. Фоновый обработчик забирает пакет outbox-записей, публикует Protobuf-события в Kafka и учитывает попытки доставки. Потребитель проверяет идентификатор события, в одной транзакции сохраняет аудит и отметку обработки, затем фиксирует Kafka offset.

Посмотреть реализацию
04

Понятное состояние сервиса

Метрики Prometheus охватывают HTTP, gRPC, кэш, outbox и потребителя Kafka. OpenTelemetry трассирует HTTP- и gRPC-запросы. Проверка готовности учитывает PostgreSQL, Redis, Kafka и остановку приложения. Завершение работы согласовано для HTTP-сервера, gRPC-сервера и фоновых обработчиков.

Посмотреть реализацию
КАК ЭТО РАБОТАЕТ

Путь одной регистрации

Сценарий регистрации и доставки события, реализованный в репозитории. Публикация идёт после транзакции базы данных.

  1. 01

    REST-регистрация

    Проверить запрос, нормализовать email и хешировать пароль.

  2. 02

    Транзакция PostgreSQL

    Вместе записать пользователя, refresh-токен и outbox-событие UserRegistered.

  3. 03

    Обработчик outbox

    Забрать пакет через SKIP LOCKED. Повторять неудачные публикации до заданного лимита.

  4. 04

    Событие в Kafka

    Опубликовать Protobuf-данные с идентификатором, типом и версией события.

  5. 05

    Транзакция потребителя

    Проверить идентификатор и сохранить аудит вместе с отметкой обработки.

  6. 06

    Фиксация offset

    Подтвердить обработку записи после успешной транзакции базы данных.

API НА ПРАКТИКЕ

Конкретные API-контракты

Несколько операций из OpenAPI-спецификации и Protobuf-описания сервиса в репозитории.

HTTP / REST

POST/auth/register
Создать пользователя и выдать пару токенов.
POST/auth/refresh
Заменить refresh-токен и выдать новую пару.
GET/auth/me
Получить текущего авторизованного пользователя.
GET/ready
Проверить зависимости и состояние остановки.
OpenAPI-спецификация

gRPC / UserService

RPCGetUser
Получить пользователя по ID.
RPCListUsers
Получить список с пагинацией, фильтром по email и сортировкой.
Protobuf-описание
ИНЖЕНЕРНЫЕ РЕШЕНИЯ

Почему устроено именно так.

01

Изменение и событие фиксируются вместе

Транзакция регистрации включает сохранение токена и запись в outbox. Тесты охватывают откат при ошибке сохранения токена или события.

Посмотреть реализацию
02

Повторная доставка ожидаема

Фоновый обработчик может повторить публикацию после сбоя. Потребитель проверяет ID события и объединяет аудит с отметкой обработки в транзакции PostgreSQL.

Посмотреть реализацию
03

Состояние обработки хранится явно

Outbox-записи проходят состояния NEW, PROCESSING, PROCESSED и FAILED. Пакет забирается с блокировкой строк; просроченные блокировки обработки можно забрать повторно.

Посмотреть реализацию
ПРОВЕРКИ И ГРАНИЦЫ ПРОЕКТА

Проверки рядом с реализацией

В репозитории есть тесты ротации токенов, отката неудачной регистрации, middleware, операций с пользователями, outbox и других частей сервиса. CI запускает короткие Go-тесты, проверку форматирования и безопасности, Protobuf, OpenAPI и сборку Docker.

Посмотреть процесс CI
  • Успешная аутентификация, неверные данные и отозванные токены
  • Откат при ошибке сохранения refresh-токена или outbox
  • Модульные тесты и отдельные интеграционные тесты PostgreSQL / Redis
  • Сборка Docker и процессы публикации в GitHub Container Registry

Самостоятельный проект с практиками промышленной разработки. Назначение и границы сервиса описаны в README.

ОТКРЫТЫЙ ИСХОДНЫЙ КОД

Go Identity Service

Перейти в репозиторий
СЛЕДУЮЩИЙ ПРОЕКТ

Intentional

05 / ДАВАЙТЕ НАЧНЁМ

Есть задача,
которую стоит решить?

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

slobodchikov2003@gmail.com

Создадим черновик письма в вашем почтовом приложении — автоматически ничего не отправляется.