Большинство backend‑проектов начинаются предсказуемо: HTTP‑запрос, бизнес‑логика, SQL и ответ клиенту. Но что изменится, если вместо очередного CRUD нужно одновременно искать собеседников, поддерживать долгоживущие WebSocket‑соединения и не допускать двойного matchmaking?

В этой статье я расскажу, как появился Fluent Swap, почему его первая версия работает без базы данных и как очередь в памяти одного Go‑процесса постепенно подводит архитектуру к Redis и горизонтальному масштабированию.

Не так давно я на ровном месте занялся написанием библиотеки на Go (spinq) для, казалось бы, тривиальной задачи — спиннера, который гарантированно не будет ломаться при конкурентных записях в stderr и stdout.

Все началось с того, что я писал вообще другой код — консольную утилиту для запуска тестов. И захотел прикрутить туда спиннер. Но не просто спиннер, а такой, что позволил бы использовать оба потока вывода — stderr и stdout, без риска оставить артефакты на экране. Более того, во время анимации мне нужно иметь возможность показывать на экране отчеты по завершившимся тестам, не откладывая это все до конца запуска/остановки спиннера. И так уж почему‑то получилось (спойлер: потому что не слишком просто, иногда совсем невозможно и мало кому нужно), что я не смог найти библиотеку, которая бы мне подошла.