stanislav_dubich@dev:~$ cat file-backup-system/README.md

File Backup System

RPA-инструмент для аварийного восстановления файлов из облачного сервиса. Java (API) + Go (воркеры). Корректная браузерная автоматизация.

Бизнес-задача

Проблема: Public API облачного сервиса не поддерживает экспорт нативных файлов. Команда из сотен человек рискует потерять работу при сбоях или блокировках аккаунта.

Решение: RPA (Robotic Process Automation). Playwright эмулирует действия пользователя: открывает файл → экспортирует → стримит в S3.

Соответствие правилам: Ограничение частоты (1 файл/воркер), паузы как у человека, корректное обращение к сервису. Инструмент для собственного контента компании, а не скрапинг чужих данных.

Архитектура

┌─────────────────┐         ┌─────────────────┐
│   Admin Panel   │──REST──▶│  Java Backend   │◀──OAuth2/JWT──▶ Keycloak
│   (Frontend)    │         │  (Spring Boot)  │
└─────────────────┘         └────────┬────────┘
                                     │
        ┌────────────────────────────┼────────────────────────────┐
        │                            │                            │
        ▼                            ▼                            ▼
┌───────────────┐           ┌───────────────┐            ┌───────────────┐
│  PostgreSQL   │           │  Figma API    │            │   Go Workers  │
│  (metadata)   │           │  (teams,      │            │  (Playwright) │
└───────────────┘           │   projects)   │            └───────┬───────┘
                            └───────────────┘                    │
                                                                 ▼
                                                         ┌───────────────┐
                                                         │  S3 / Yandex  │
                                                         │  Object Store │
                                                         └───────────────┘

Почему Java + Go

Изоляция ресурсов: Headless Chrome потребляет 500MB+ RAM на сессию и может утечь. OOM в браузере не должен убивать админку.

Java Backend: REST API, OAuth2, JPA ORM, сложная бизнес-логика (лицензии, роли, синхронизация)
Go-воркеры: Изолированные процессы с Playwright. Падение воркера не влияет на API. Независимый рестарт без простоя
Результат: Горизонтальное масштабирование. 1 API-сервер + N воркеров. Воркеры без состояния — можно убивать/рестартить

Сервис загрузки (Go)

Пул воркеров с очередью задач на PostgreSQL:

4 воркера: каждый со своей Playwright-сессией
Очередь задач: SELECT ... FOR UPDATE SKIP LOCKED для атомарного захвата без гонок
Приоритеты: SCHEDULED → ERROR (повтор через 12 мин) → NONE/UPDATE
Стриминг в S3: файлы стримятся напрямую в Object Storage без загрузки в память (важно для файлов 1GB+)

Обработка ошибок:

Файл не найден / нет доступа → пропуск
Таймаут (большой файл) → повтор с экспоненциальной задержкой
Превышен лимит → адаптивная пауза между запросами

Java Backend

Синхронизация: импорт teams/projects/files через Public API + Browser для приватных данных
Управление лицензиями: массовый CSV-импорт, назначение ролей (Editor/Viewer), отслеживание сроков
Два аккаунта: обычный для чтения, admin для управления лицензиями (разделение обязанностей)
Пакетная обработка: Hibernate batch_size=250 для синхронизации сотен файлов

Стек

Java Backend

Java 21 Spring Boot 3.4 Spring Security OAuth2 Spring Data JPA

Go Workers

Go 1.23 Playwright-go pgx/v5 (PostgreSQL) Viper (config) Logrus (logging)

Data

PostgreSQL 16 Liquibase S3 / Yandex Object Storage

Infra

Docker (multi-stage) Keycloak (OAuth2) GitHub Actions Yandex Container Registry

Моя роль

Архитектура polyglot-системы с изоляцией ресурсов (Java API + Go-воркеры)
RPA через Playwright с корректным обращением к сервису и ограничением частоты
Очередь задач на PostgreSQL (FOR UPDATE SKIP LOCKED) без гонок
Потоковая загрузка в S3 для больших файлов

← На главную