Serviss All File Converter ir izstrādāts kā mērogojama, distribuēta SaaS sistēma, kuras pamatā ir mūsdienīgs Python 3.12 asinhronais steks. Arhitektūra ir sadalīta neatkarīgos slāņos: tīkla notikumu uztveršana, uzdevumu orķestrēšana, smago bināro procesu izolēta izpilde un analītiskais kontūrs.

1. Kopējais tehnoloģiju steks un sistēmas arhitektūra

Platformas pamatā ir augstas veiktspējas (high-throughput), minimāla atmiņas patēriņa un kļūmju drošības principi:

  • Telegram Bot Framework: Aiogram 3.13, kas darbojas Webhook režīmā ar drošu marķieru (token) validāciju un pielāgotiem ziņojumu dzīves cikla filtriem.
  • Tīmekļa vārteja un REST API: FastAPI uz Uvicorn ASGI servera bāzes ar asinhronu bināro failu straumēšanu (FileResponse) un fona tīrīšanu, izmantojot BackgroundTasks.
  • Rindu brokeris un kešatmiņa: Redis 7 (Celery uzdevumu pārvaldība, sacensību apstākļu (race condition) bloķēšana, aizsardzība pret brute-force, sesiju kešatmiņa).
  • Fona izpildītājs (Task Queue): Celery 5.4 ar dedrēticotu darbinieku (worker) pool izolētā converter_worker konteinerā.
  • Datubāze: PostgreSQL 16 ar ORM slāni SQLAlchemy 2.0 (asyncpg), pastāvīgo savienojumu pool (20+10 overflow) un kļūdaino transakciju automātisko atkārtošanu (@db_retry).
  • Tīkla kontūrs: Tunelēšana, izmantojot Cloudflare Zero Trust, ar tiešas IP piekļuves bloķēšanu serverim caur Middleware.

2. Asinhronās rindas un smago aprēķinu izolācija (Celery + Redis)

Multivides failu un biroja programmatūras pakešu konvertēšana rada pīķa slodzi uz CPU un RAM. Lai ienākošo ziņojumu apstrādes process Telegram netiktu bloķēts smagu operāciju laikā, ir ieviesta stingra izolācija:

  • Uzdevumu deleģēšana uz Redis: Izvēloties formātu, Telegram apstrādātājs reģistrē uzdevumu datubāzē ar statusu PROCESSING un ievieto uzdevumu rindā tasks.execute_conversion, izmantojot Celery.
  • Izolēts darbinieka konteiners: Konvertēšanas utilītu izpilde notiek atsevišķā Linux konteinerā ar savu procesora laika un atmiņas limitu.
  • Iesprūšanas kontrole un taimauti: Ārējo utilītu izsaukumi ir ietverti asinhronā kontekstā ar stingru laika kontroli (conversion_timeout_sec = 180). Pārsniedzot limitu, process tiek piespiedu kārtā pārtraukts, izmantojot proc.kill(), tādējādi atbrīvojot resursus.
  • Noturīgs Fallback: Redis brokera īslaicīgas nepieejamības gadījumā uzdevumu automātiski pārtver lokālais asinhronais dispečers un tas tiek izpildīts tieši, neradot kļūmi lietotājam.

3. Specializēto konvertēšanas dzinēju konveijers

Katram datu tipam tiek izmantotas šauri specializētas vietējās (native) utilītas un bibliotēkas:

  • Dokumenti un tabulas (LibreOffice): Bezgalvas biroja pakotne (soffice --headless) DOCX, XLSX, PPTX, RTF, ODT precīzai renderēšanai PDF vai teksta failos.
  • Straumēšanas audio un video (FFmpeg): Videokodeku (H.264) un audiokodeku (MP3, OGG Opus) daudzplūsmu pārkodēšana, skaņu celiņu izgūšana, GIF ģenerēšana (Lanczos filtrs) un Telegram vide ziņojumu kvadrātveida kadrēšana (1:1).
  • Augtrāža PDF apstrāde (Poppler Utils): Utilītas pdftotext (formatēta teksta tūlītēja izgūšana UTF-8 formātā) un pdftoppm (PDF renderēšana pa lapām rastra attēlos bez LibreOffice pieskaitāmajām izmaksām).
  • Optiskā rakstzīmju atpazīšana (Tesseract OCR): Neironu tīkla teksta izgūšana no skenējumiem un fotoattēliem vairāk nekā 40 valodās.
  • Rastra un vektora grafika: Bibliotēkas Pillow (tostarp HEIC un AVIF formātu atbalsts), CairoSVG vektora attēliem un lottie Telegram animētajiem uzlīmēm (.TGS).
  • Grāmatas, subtitri un fonti: Dzinējs Calibre (ebook-convert), subtitru parsētājs pysubs2 (SRT, VTT, ASS, SSA) un fontu kompilators fonttools (Brotli saspiešana WOFF2 formātā).

4. Preventīvā resursu aizsardzība (System Guard)

Lai pasargātu serveri no avārijas atmiņas trūkuma dēļ (OOM Killer), ir ieviests preventīvās diagnostikas serviss System Guard. Pirms faila pieņemšanas apstrādei sistēma pārbauda galvenos resursdatora (host) rādītājus:

  • Brīvā operatīvā atmiņa (RAM): Vismaz 500 MB brīvā apjoma (guard_min_free_ram_mb).
  • Diska vieta: Vismaz 2 GB brīvās vietas direktorijā /tmp (guard_min_free_disk_mb).
  • Uzdevumu rinda: Celery rindas garuma ierobežojums (ne vairāk kā 20 gaidoši uzdevumi).

Pārsniedzot limitus, serviss uz laiku ieslēdz aizsardzību (HTTP 503 / ziņojums tērzētavā), novēršot servera pārslodzi un nosūtot tūlītēju brīdinājumu administratoriem vietnē Telegram.

5. Failu dzīves cikls un drošība (GDPR)

Arhitektūra ir izstrādāta pēc Zero-Data-Footprint modeļa:

  • Lietotāju faili tiek augšupielādēti aizsargātā sējumā tmp/conversions/ ar unikāliem prefiksiem, kuru pamatā ir uzdevumu identifikatori.
  • Faili paliek pieejami stingri darba sesijas ietvaros — ne ilgāk kā 15 minūtes (900 sekundes).
  • Automātiskais atkritumu savācējs izdzēš oriģinālos un gatavos failus uzreiz pēc veiksmīgas nosūtīšanas apstiprinājuma tērzētavā vai pēc sesijas taimauta beigām.
  • PostgreSQL datubāze neuzglabā bināros failus vai personīgos dokumentu tekstus — tabulās tiek fiksēti tikai anonimizēti tehniskie metadati (formāti, izmēri baitos, darbības laiks, statusi).

6. Universāls REST API ārējiem tīmekļa pakalpojumiem

Serviss jau no paša sākuma ir projektēts kā daudzplatformu aizmugursistēma (backend). Līdzās botam darbojas pilnvērtīgs, aizsargāts programmatūras saskarsme (API) tīmekļa vietnēm (piemēram, uz Django bāzes) un trešo pušu botiem:

  • GET /api/v1/formats — pieejamo konvertēšanas virzienu dinamiskā JSON matrica, kas sinhronizēta ar Google Sheets iestatījumiem.
  • POST /api/v1/convert — universāla galapunkta (endpoint) adrese, kas pieņem multipart/form-data (failu, mērķa formātu, ārējā klienta ID) un atdod gatavu baitu plūsmu tiešas lejupielādes veidā.
  • Autorizācija, izmantojot Bearer marķierus (WEBHOOK_REFRESH_TOKEN) ar aizsardzību pret laika uzbrukumiem, izmantojot secrets.compare_digest.

7. Vadības panelis un Observability (NiceGUI + AG Grid)

Biznesa rādītāju un sistēmas stāvokļa uzraudzība ir izvesta uz vietējo Single-Page vadības paneli, kurš balstīts uz NiceGUI 2.x:

  • Interaktīvas tabulas AG Grid (v32+) ar pielāgotiem Excel stila izvēles rūtiņu (checkbox) filtriem (aggrid_filters.js).
  • Rindu, API nodrošinātāju aizkavju un PostgreSQL / Redis ping reāllaika uzraudzība.
  • Caurgājuma filtrēšana pēc datumiem ar bezšuvju Metabase BI informācijas paneļa integrāciju, izmantojot parakstītus JWT marķierus.