Еще хочу сказать, что я считаю есть вот два показательных типа проектов: 1) сервис который ты будешь использовать в другом своем сервисе и это заставляет делать его минималистичным, неизменяемым, «идеальным» 2)реалистичный проект - люди придумывают языки и технологии, приудмывают архитектурные подходы, качество архитектуры выражается ее гибкостью, соответсвенно нужно придумать и вести постепенно расширяемый проект, иногда ты сам будешь себе палки в колеса вставлять придумывая новую фичу, иногда при масштабировании какого-то куска кода тебе придется покапаться в абстракциях и синхронизировать доступ к чему-то. Вся сложность приложений в слое бизнес логики, интегрироваться с технлогиями само по себе просто, их простыми проектируют, реально сложно это вести проект так, чтобы его можно было безболезненно расширять и менять.

Ну и старайся сходу следовать бест практайсам, и требованиям к современному бэкенд ПО

Привет, мне кажется стоит отталкиваться от того с какими технологиями работают компании с вакансиями на твоем языке, и учитывать специфичные требования этого бизнеса, например .net это про банки, банки в свою очередь про безопасность, аудит и требования к консистенции данных, можешь попробовать реализовать систему платежей с использованием кафки, отработать паттерны распределенных транзакций, двойного подтверждения обработки, вообщем начать с двух сервисов и накрутить на это хайповых технологий. Думаю от бэкенд разработчика в банке нужно уметь хорошо встраиваться в существующую архитектуру и реализовывать безопасность + обсервабилити Свяжи там два сервиса асинхронно через кафку и два сервиса синхронно через grpc, интегрируйся с фнс, чтоб актуальные курсы валют получать, сделай крон таску формирующую отчеты по транзакциям за месяц. Что-то такое в голову приходит