Python Backend Engineer

На данный момент Python Backend Engineer FinTech.

Мои компетенции и опыт

ПРОФИЛЬ

• 15+ лет в веб-разработке и инженерии: от «полного цикла» (разработка+деплой+администрирование) до проектирования распределённых финтех-систем.
• Коммерческий опыт на Python 3+ лет (Django/DRF, FastAPI), REST API, асинхронность, интеграции, безопасность.
• Сильный клиентский JavaScript (браузерный): ES6+, vanilla, jQuery; опыт современного фронтенда на Vue 3 (SPA).
• Финтех-домен: виртуальные карты, внутренние счета/балансы, обработка уведомлений, крипто-пополнения TRON TRC-20.
• Стиль работы: системный подход, выбор архитектуры через trade-offs (надёжность/риски/поддержка/стоимость), прозрачная коммуникация (план/статусы/блокеры/риски).

ПРОЕКТЫ

КЕЙС 1

 Криптопроцессинг пополнений через TRON TRC-20

Роль: проектирование архитектуры + реализация ключевых компонентов

Контекст

• Система пополнения внутреннего счета криптовалютой TRON (TRC-20).
• Требования: безопасность ключей, устойчивость к сбоям, гарантированная фиксация событий.

Ключевые решения (архитектура)

• Трёхкомпонентная схема с жёсткой изоляцией критичного слоя:

1. Публичный слой (клиентские статусы/выдача адресов)
2. Оркестратор состояния (учёт, статусы, интеграция с основной системой)
3. Изолированный блокчейн-сервис (генерация адресов, хранение ключей, воркер наблюдения и переводов)

• Принцип безопасности: блокчейн-сервис не инициирует коммуникацию наружу; оркестратор сам опрашивает состояние. Это снижает риск потерь событий из-за проблем доставки и упрощает восстановление.
• Масштабирование: дублирование сервисов без конфликтов за счёт разделения пула адресов.

Что сделал (реализация)

• Реализовал API/учёт и логику выдачи адресов, статусы, схемы хранения событий.
• Реализовал воркер наблюдения за входящими транзакциями и перевод на постоянный адрес.
• Предусмотрел неопределённости блокчейна (комиссии, повторные транзакции, задержки подтверждений) как сценарии обработки.

Результат

• Архитектура, рассчитанная на финтех-риски: изоляция ключей, отказоустойчивость, масштабируемость.
• Управляемая синхронизация состояния через pull-модель (опрос источника истины).

Технологии: Python (Django/DRF по компонентам), Docker, Linux, TRON (TRC-20) через Python-библиотеки, SQL (практический уровень).

КЕЙС 2 - Интеграция Wallester (виртуальные банковские карты)

Роль: ведущий разработчик/архитектор интеграции

Контекст

• Нужно было внедрить выпуск и управление виртуальными картами через внешнего провайдера.
• Критичность: деньги, уведомления о транзакциях, риски потери событий и рассинхронизации.

Что сделал

Спроектировал архитектуру с отдельным «прокси-слоем» для входящих уведомлений:

• немедленное подтверждение приёма провайдеру + сохранение события;
• асинхронная доставка в основную систему;
• возможность recovery (переобработка по архиву);

Реализовал многоуровневую защиту качества данных:

• полное логирование и аудит событий;
• дедупликация повторных уведомлений (идемпотентность);
• классификация аномалий (знаки сумм, закрытые карты, неожиданные типы событий);

Решил задачу консистентности при параллельных операциях: - очередь обработки уведомлений (последовательно, без гонок) + гарантированное обновление баланса/истории.

Безопасность: JWT для API, RSA для чувствительных данных, хранение секретов вне публичного контура.

Клиентская часть:

• интегрированный пользовательский банк-клиент для управления и контроля карт;
• автоматическое списание подписок и комиссий, временные блокировки, закрытие карты с выводом остатка.

Результат

• Production-готовая интеграция, устойчивость к сбоям и повторам провайдера.
• Полный архив входящих событий (forensics + восстановление).
• Предсказуемая обработка уведомлений и отсутствие «тихих» потерь данных.

Технологии - PHP, JS, REST/Webhook, криптография (JWT/RSA), Linux, Nginx/Apache, SQL (практический уровень).

Решение

Встроенная очередь запросов в БД по account_id:

• запись операции в очередь (PENDING) + попытка захвата lock по счёту;
• single-thread обработка операций одного счёта в порядке поступления;
• журнал состояния/аудит (balance_before/after, тип операции, сумма, время);
• проверка «новые задачи пришли во время обработки» и повтор цикла до пустой очереди.

Почему так: избегаем длительных блокировок на время внешних API и сохраняем throughput.

Результат

• Убраны гонки и перезапись состояния при конкурентной нагрузке.
• Появился детальный аудит: что и почему изменило баланс.

Технологии - SQL/транзакции (практический уровень), очереди/локи на уровне схемы БД, сервисная архитектура.

Другие кейсы:

• AI ассистент: FastAPI, Gemini API, vanilla JS;
• Chrome extension: vanilla JS; FastAPI; нужен доступ к резюме

GitHub:

Для демонстрации решений из области финтеха я разместил репозитории код в репозиториях:

• fintech_demo_expense_tracker_fastapi
• fintech_demo_vue_financial_dashboard
• fintech_demo_transaction_manager_django
• fintech_demo_microservices_financial
• fintech_demo_laravel_invoice_system