Miliardy małych plików, jeden bezstanowy system konsolidacji.
Deterministyczne kierowanie, niezmienne shardy, S3 jako jedyne źródło prawdy.
Zaprojektowane dla skali, w której tradycyjne magazyny obiektowe przestają być ekonomiczne.
Wbudowana zgodność z SEC 17a-4, HIPAA, GDPR i SOC 2 — od pierwszego shardu.
Każda organizacja przechowująca miliardy małych plików staje przed tym samym napięciem: koszty rosną liniowo z liczbą obiektów, a regulator wymaga lat retencji z udokumentowaną niezmiennością.
S3 ekonomicznie obsługuje obiekty MB-GB, nie KB. Miliard plików po 50 KB to nie tylko storage — to miliard wywołań LIST, GET, PUT. Faktura za API potrafi przewyższyć fakturę za samo przechowywanie danych.
Każda operacja masowa wymaga miliardów wywołań API. Pełna replikacja regionu trwa tygodniami. Disaster recovery 100M plików to projekt wielomiesięczny. Każda operacja na poziomie obiektu osobno — bez konsolidacji nie ma skalowania.
Regulatorzy wymagają niezmienności (S3 Object Lock COMPLIANCE). RODO wymaga prawa do usunięcia. Bez warstwy aplikacyjnej każde takie żądanie wymaga ręcznego obejścia. Audytor widzi albo złamane WORM, albo nieusunięte dane.
Klasyczne systemy archiwizacji potrzebują centralnej bazy mapującej plik → lokalizacja. Baza staje się wąskim gardłem, koordynatorem, single point of failure. Im więcej plików, tym większy problem. Coordination tax rośnie wykładniczo.
Inteligentna konsolidacja małych plików w niezmienne kontenery .vera, deterministyczne kierowanie bez bazy danych, S3 Object Lock i tombstone GDPR — wszystko w jednym systemie.
Tysiące małych plików scalanych w binarne kontenery .vera zoptymalizowane pod S3. Pojedyncze obiekty S3 zamiast miliardów — backup, replikacja i lifecycle policies wreszcie działają w sensownym czasie.
Indeks zapisany w stopce sharda. Pobranie pojedynczego pliku z miliarda to dwa wywołania S3: jedno na indeks (cache'owany), drugie na zakres bajtów. Bez ściągania całego kontenera, bez bazy zewnętrznej.
<100ms latencyPer-shard metadata sidecar (.vera.meta) z tombstone'ami plików. Dane logicznie usunięte, fizyczny shard niezmienny. Po przekroczeniu progu — repack do nowego sharda. Audytor widzi udokumentowaną mutację, nie złamane WORM.
Heurystyka per-plik: zstd dla danych tekstowych (3–6× ratio), pomijanie już skompresowanych (JPEG, MP4, ZIP). Bez narzutu CPU tam, gdzie kompresja nic nie da, z agresywną kompresją tam, gdzie się opłaca.
40–70% mniej miejscaS3 Object Lock (COMPLIANCE), Extended Retention Management, dziennik audytu z chain hash, Ed25519/RSA PKI dla uwierzytelnienia operatorów, OpenBao/Vault dla sekretów. Bez doklejania compliance na koniec projektu.
SEC / HIPAA / GDPR / SOC 2Tysiące jednoczesnych procesów pakujących, każdy działa niezależnie. Dystrybucja pracy przez kolejki (SQS / Kafka / RabbitMQ). Kubernetes HPA jako natywny model skalowania. Brak elekcji lidera, brak race conditions.
10 000+ plików/min
Kluczowa właściwość VERA: brak bazy danych mapującej plik na lokalizację.
Funkcja locate_shard(uid, created_at, n_bits) jest czystą funkcją — daje deterministyczny adres sharda bez koordynacji, bez konsultacji z żadnym stanem zewnętrznym.
Każdy proces — pakujący, czytający, migrujący — niezależnie wie, gdzie leży plik. Skalowanie do tysięcy worker'ów to dodanie podów do K8s, nie zmiana architektury. S3 jest jedynym źródłem prawdy. Reszta jest odtwarzalna.
Rzeczywiste scenariusze dla organizacji, które muszą archiwizować miliardy małych plików przez lata, z udokumentowaną zgodnością.
Banki i firmy inwestycyjne muszą przechowywać miliardy PDF-ów, potwierdzeń, skanów transakcji przez 5–7 lat (SEC 17a-4, KNF). Klasyczne S3 sprawia, że sama faktura za API rośnie szybciej niż wolumen danych.
Szpitale archiwizują setki milionów rekordów pacjentów, wyników badań, miniatur DICOM. HIPAA wymaga 6+ lat retencji z dziennikiem dostępu, RODO daje pacjentowi prawo do usunięcia danych osobowych.
Operatorzy generują miliardy rekordów CDR dziennie. Wymóg przechowywania 3–5 lat, dostęp punktowy na żądanie organów ścigania. Wolumen ciągle rośnie, każdy dzień to nowy backlog.
Urzędy centralne, sądy, ZUS, NFZ, instytucje skarbowe — miliardy podań, wniosków, decyzji administracyjnych. Wymóg retencji 10–50 lat, dostępność dla audytów i postępowań przez całą dekadę.
VERA spełnia wymagania regulacyjne architekturą, nie konfiguracją na koniec projektu. Niezmienność, audit trail i tombstone GDPR są pierwotnymi pojęciami systemu.
Shardy blokowane natychmiast po finalizacji. Tryb GOVERNANCE (usunięcie z MFA + uprawnieniem break-glass) lub COMPLIANCE (nieusuwalne w żadnych okolicznościach). Retencja konfigurowalna per shard.
Per-shard sidecar .vera.meta z tombstone'ami. Dane logicznie usunięte natychmiast, fizyczny repack po przekroczeniu progu (typowo 30% tombstone'ów). SLA 48h od żądania do usunięcia widoczności.
Przedłużenie retencji indywidualnego pliku bez kopiowania całego sharda. Wykorzystanie S3 Object Lock retention period na podzbiorze. Pełna integracja z business systemami przez API.
Każda operacja (PACK, READ, DELETE, REPACK, RETAIN) logowana z kryptograficznym powiązaniem z poprzednim wpisem. Wykrycie usunięcia lub edycji dziennika audytu jest deterministyczne.
Każdy administrator i workflow uwierzytelniony przez Ed25519 lub RSA. Brak zaszytych poświadczeń. Sekrety w OpenBao / Vault z dynamic credentials i krótkim TTL. Rotacja kluczy bez przerwy w działaniu.
Każdy eksport zawiera integrity_proof.json z hashami shardów, potwierdzeniem WORM i, jeśli dotyczy, ścieżką repack anchor entries. Gotowy do przekazania audytorowi, KNF lub prokuraturze.
Cztery warstwy bez wspólnego stanu — pakowanie, indeksowanie, retrieval i lifecycle management działają niezależnie i skalują się osobno.
Watermark-based migracja z bazy źródłowej. Kompresja per-plik z heurystyką. Append-only zapis do sharda. Bezstanowe — każdy worker bierze slot z watermarka i działa niezależnie.
Czysta funkcja locate_shard(uid, created_at, n_bits). Brak bazy lookup. O(1) bez zewnętrznych zależności. Każdy proces niezależnie wie, gdzie szukać dowolnego pliku.
FastAPI / Quarkus. S3 Range-GET na podstawie indeksu w stopce sharda. Cache indeksów 16 GB (rebuild z S3). Stateless pody za load balancerem, K8s HPA skaluje pod ruch.
Sidecar .vera.meta z tombstone'ami. CronJob monitoruje próg, uruchamia repack do nowego sharda. Repack anchor entries zachowują ciągłość audit trail. Stary shard archiwizowany do Glacier.
| Komponent | Technologia | Uzasadnienie |
|---|---|---|
| Runtime (v1.x) | Python 3.11 + FastAPI | Sprawdzona stabilność, bogata integracja z bazami SQL |
| Runtime (v2.x) | Java 21 + Quarkus | Native image, non-blocking I/O, ~2.5 mld plików/rok skala |
| Object storage | S3-compatible | AWS S3, MinIO, Ceph/RGW, Wasabi, Dell EMC, NetApp |
| Format sharda | .vera append-only | [HEADER][DATA][INDEX][FOOTER] — Range-GET friendly |
| Kompresja | zstd / lz4 (auto) | Heurystyka per-plik · pominięcie już skompresowanych |
| Database source | SQLAlchemy | PostgreSQL · MySQL · SQLite · watermark migration |
| Sekrety | OpenBao / Vault | Dynamic credentials · krótki TTL · MFA dla break-glass |
| Authentication | Ed25519 / RSA PKI | SSH-style podpisywanie · zero hardcoded credentials |
| Orchestration | Kubernetes | CronJob dla repacku · HPA dla retrievera · Helm charts |
| Queue (planowane) | SQS / Kafka / RabbitMQ | Praca dystrybuowana · event-driven scaling |
| Observability | Prometheus + Grafana | Alert: des_pack_lag >30min → PagerDuty |
Skontaktuj się z nami, aby omówić wdrożenie VERA w Twojej organizacji, uzyskać wycenę albo zadać pytanie techniczne dotyczące architektury, integracji lub planu migracji.