LinkedIn: https://www.linkedin.com/in/vlad-naut-193bb3103/ 1. Некоторые мои пет-проекты: https://github.com/naut92?tab=repositories 2. Тестовые задания, код онлайн не пишу. 3. Если работодатель - резидент РФ, то оформление на ИП жены - резидента РФ. Либо B2B как налоговый резидент Грузии. Пример проекта докеризации приложения: https://www.youtube.com/watch?v=acrP2X3DsfY&ab_channel=javadev Курсы Red Hat по докеризации и кубернетс: https://drive.google.com/file/d/11uwi0pGigqzfQeJ1yfqk9CRfDaygyyaC/view?usp=sharing Пример проекта: хранение истории баланса клиента (включая откаты и пересчёты); • гибкие тарифные планы (предоплата/постоплата, дата- и объем-зависимые); • списания по событиям (SMS, звонки, интернет); • уведомления о балансе и авто-платежи. Начинаю с проектирования ядра — модели данных. Тарифная система — это сердце. Я выделяю ключевые сущности: • Customer — пользователь (связь 1:N с SIM-картами, платежами) • Subscription — активная подписка (статус, срок, тариф) • TariffPlan — конфигурация тарифа (лимиты, цены, политика списания) • UsageEvent — детализация событий: звонок, SMS, data session • BalanceChange — запись любого списания или пополнения • Invoice / Payment — биллинг, транзакции Проектируя таблицы, ввожу временные индексы и soft-deletion, чтобы поддерживать аудит и восстановление. Учитываю возможную денормализацию для отчётности. 2. Прогнозирую узкие места: • Высокая нагрузка по записи в UsageEvent, особенно при роуминге → создаю партицированную таблицу по дате и user_id. • Баланс должен быть консистентным, но без блокировок → применяю event sourcing через BalanceChange + агрегированное кеширование. 3. Строю архитектуру: • Микросервисы: Billing Core, Tariff Engine, Usage Collector, Notification Service, API Gateway • Kafka для асинхронной доставки Usage Events • Redis для кеша балансов • PostgreSQL с логической репликацией в read-only DB для отчётов • gRPC между core-сервисами + REST наружу Что я предвидел и избежал: • Клиент хотел “баланс пересчитывать по cron”, но я объяснил, почему event sourcing даст лучшее масштабирование и консистентность, и ввёл append-only структуру BalanceChange. • В логике тарификации была попытка жёстко захардкодить поведение — предложил вынести в динамическую конфигурацию TariffPolicy (в JSON + validation), что ускорило time-to-market новых тарифов. • Для отчётности менеджмент просил JOIN через 6 таблиц в онлайн-режиме — ввёл денормализованный BalanceSnapshot по расписанию и обеспечил near real-time выгрузку без нагрузки на live БД.