Arsitektur independen dan kapasitas — DW E-Recruitment
Versi 0.5 · 10 Oktober 2026 · Target desain AI + SAW, bukan konfigurasi produksi.
1. Batas kepemilikan
DW milik Devworks; Biproo milik pihak berbeda. Flow lowongan–lamaran–screening–review hanyalah referensi proses umum. Tidak ada migrasi data, salinan source proprieter, akun bersama, atau integrasi antarpemilik dalam blueprint ini.
| Area | Rancangan DW |
|---|---|
| Codebase dan release | Modul/repository Go dan pipeline deployment DW sendiri |
| Identitas | Akun kandidat/recruiter DW; session, RBAC, scope organisasi, dan audit sendiri |
| Database | PostgreSQL dw_recruitment dengan role dan migration khusus; tidak memakai database produk lain |
| Dokumen | Bucket privat DW, object key scoped, retention policy dan akses terotorisasi |
| Antrean/cache | Instance atau namespace DW dengan ACL/service identity; tidak berbagi payload/cache Biproo |
| Secret | Kredensial, signing key, enkripsi dan AI service identity DW; bukan secret pemilik lain |
| Eksperimen | Dataset DW berizin/sintetis, bukan CV produksi milik pihak lain |
| Backup | Backup DW terenkripsi, akses terbatas, dan latihan restore terisolasi |
Mesin inference Devworks dapat menjadi infrastruktur bersama antar-layanan yang diizinkan dengan isolasi request, artifact, kuota, dan akses. Ini tidak mengizinkan akses data Biproo. Alokasi runtime terpisah dapat dipilih bila isolation/capacity memerlukannya.
2. Komponen target
Tiga portal → reverse proxy/TLS → API Go modular → PostgreSQL, storage privat, outbox/dispatcher → Redis Streams → pipeline worker.
API Go memuat auth, kandidat, lowongan, lamaran, screening, review, dan audit; domain FPK, assessment, interview, training, onboarding, kontrak, laporan dan integrasi ditambahkan bertahap sesuai rancangan platform. Mulai dengan modular monolith agar aturan bisnis konsisten; worker dijalankan sebagai proses terpisah dan dapat ditambah replica. Microservice/Kubernetes tidak wajib untuk membuat pipeline kuat.
| Pool | Tugas | Kendali kapasitas |
|---|---|---|
| Scan/validasi | Pemeriksaan file, keamanan, checksum, dan karantina | Ukuran file, timeout, sandbox parser |
| Ekstraksi/OCR | Inventaris halaman, teks, OCR halaman scan/hibrida | CPU/RAM, page concurrency, kualitas OCR |
| Inference | Ekstraksi fakta per chunk dan penilaian berbukti | Batas context/token, VRAM, runtime concurrency, timeout |
| Scoring/agregasi SAW | Validasi aspek, baseline absolut, snapshot maksimum per batch, normalisasi SAW, ranking dan versi artifact | Barrier semua item terminal, konfigurasi seragam, idempotency, transaksi/snapshot konsisten, pengujian deterministik |
| Laporan/notifikasi | Ekspor, progres, dan pekerjaan nonkritis | Queue terpisah supaya tidak menahan inference |
Scoring dapat berupa tahap dalam worker Go, bukan harus layanan baru. Tool OCR/inference boleh memakai runtime khusus di balik adapter. Domain bisnis tetap Go.
3. Antrean yang dapat dipulihkan
- API membuat batch, item, dan event outbox dalam satu transaksi PostgreSQL; respons diterima segera tanpa menunggu AI.
- Dispatcher membaca outbox, menerbitkan ke stream DW, lalu menandai publikasi. Crash dapat menghasilkan publikasi ulang; event membawa idempotency key.
- Consumer group membagi tugas; worker mengklaim record dengan lease/versi pada database. Hasil dan event tahap berikutnya disimpan atomik dengan status tahap.
- Pesan di-ACK setelah outcome durable. Pesan tertunda dapat diambil ulang setelah lease usang; worker heartbeat dan timeout mencegah claim aktif diambil terlalu dini.
- Gangguan sementara memakai exponential backoff/jitter serta jumlah attempt terbatas. Gagal permanen masuk dead-letter; replay manual wajib authorization dan audit.
- Reconciler mendeteksi item macet atau event hilang dan menerbitkan ulang dari status/outbox. Antrean memiliki persistence, retention, monitoring, serta strategi recovery.
Semantik target at-least-once, bukan klaim exactly-once. Handler idempotent, unique constraints, dan compare-and-swap status mencegah artifact duplikat; external inference yang terulang tetap mungkin terjadi. PostgreSQL menjadi sumber status durable, Redis bukan satu-satunya tempat menyimpan progres.
Consumer groups, pending entries, acknowledgement, dan reclaim didukung Redis, tetapi outbox, retry, lease, deduplication, serta dead-letter tetap harus diimplementasikan aplikasi. XREADGROUP, XAUTOCLAIM.
4. Pemrosesan CV lengkap dan berbukti
Dokumen diinventarisasi per halaman. Halaman teks diekstrak; halaman scan atau gambar relevan menjalani OCR. Halaman identitas/lampiran tidak dinilai sebagai kompetensi, tetapi metadata pengabaian dipertahankan.
Chunking berdasarkan halaman/struktur dokumen mempertahankan span bukti. Fakta digabung dan deduplikasi sebelum scoring; persyaratan lowongan menjadi acuan. Jika context tidak memuat semua bukti sekaligus, gunakan pemilihan bukti relevan yang terukur dan catat yang tidak masuk. Tahap penggabungan tetap diuji agar fakta tidak hilang atau tertukar.
CV panjang tidak otomatis dipotong ke batas lama. Tetap terapkan upload quota, page budget, token budget, timeout, dan status partial. Dokumen yang melebihi anggaran mendapat alasan jelas dan jalur review, bukan keluaran seolah semua halaman telah dibaca.
5. Progres dan pengalaman portal
SSE atau polling terotorisasi menampilkan status per tahap: queued, scanning, extracting, inferencing, scoring, completed/partial/failed. SSE merupakan pilihan transport, bukan sumber status; reconnect mengambil snapshot database dan melanjutkan dari cursor event.
Status item terminal berbeda dari kesiapan ranking batch. Agregator SAW menunggu seluruh item terminal, membekukan source run dengan konfigurasi seragam, lalu menghitung maksimum/normalisasi atas hasil lengkap valid saja. Partial/gagal tetap terlihat dengan alasan. Ranking-run memiliki status sendiri; tanpa hasil valid tidak ada ranking. Perubahan anggota, skor, atau bobot menghasilkan snapshot baru, bukan menimpa urutan lama.
Event hanya boleh diterima recruiter/organisasi berwenang; jangan memasukkan teks CV dalam channel progres. Kandidat melihat status lamaran yang disetujui untuk publikasi, bukan catatan screening internal. Pagination/filter server-side dan ekspor asinkron menjaga UI responsif pada dataset besar.
6. Model, rubric, dan eksperimen
Model registry merekam identitas, checksum, runtime, context, parameter sampling, dan status baseline/candidate/active/retired. Rubric lowongan, prompt, ekstraktor, OCR, dan algoritme scoring memiliki versi.
Baseline lokal yang teramati adalah Qwen3-VL 8B quantized. Kandidat model lebih besar atau multimodal diuji terhadap kualitas bukti, ranking, latency, throughput, dan penggunaan resource; deployment bergantung kompatibilitas perangkat yang benar-benar tersedia. Tidak mengasumsikan GPU NVIDIA atau kapasitas tak terbatas.
Uji perbandingan offline menggunakan konfigurasi beku. Hasil per versi tidak ditimpa; aktivasi versi baru tidak menjadikan cache lama valid. Kegagalan model menghasilkan retry/fallback terkontrol dan label versi aktual.
Cache aspek AI berbeda dari cache ranking SAW. Ranking mengikat versi metode, lowongan/batch, keanggotaan/source scoring-run, bobot, dan vektor maksimum. Aspek valid dapat dipakai ulang tanpa inference, tetapi nilai SAW harus dihitung ulang jika pembanding berubah. Spesifikasi SAW DW.
7. Observability dan resource control
Trace ID menghubungkan request, batch, halaman, model call, dan artifact. Metrik: queue depth/age, throughput tiap tahap, latency p50/p95/p99, retry/DLQ, extraction coverage, invalid output, token usage, cache hit, CPU/RAM/VRAM, serta kapasitas disk.
Gunakan instrumentation Go, misalnya OpenTelemetry, dengan logs/metrics/traces tanpa CV atau secret. Dokumentasi OpenTelemetry Go.
Kendalikan semaphore per pool, rate limit per organisasi, backpressure, database connection pool, storage quota, dan headroom untuk layanan lain. Pool inference tidak dibuka tanpa batas; antrean menjadi penyangga dan metrik menentukan penambahan kapasitas.
Transaksi dan kontrol konkurensi database melindungi perubahan status; isolation level/locking harus dipilih dan diuji pada claim/review yang bersaing. PostgreSQL concurrency control.
8. Tahapan implementasi DW
| Tahap | Hasil yang perlu dibuktikan |
|---|---|
| A — Fondasi terisolasi | Go API, auth/scope, PostgreSQL/bucket DW, migration, secret, backup/restore |
| B — Screening inti | Upload, pipeline per halaman, model adapter, scoring, bukti, review, audit |
| C — Kualitas dan kapasitas | Pilot skripsi, model/rubric benchmark, load/soak, worker recovery, DLQ, observability |
| D — Platform lengkap | Talent pool, workflow interview, notifikasi, laporan dan integrasi yang disetujui |
| E — Scale-out bila dibutuhkan | Worker node tambahan, inference replica, storage/database HA, disaster recovery |
Akses penuh pada satu server bukan high availability. Menambah worker di mesin yang sama tidak menggandakan CPU/VRAM. Multi-node/HA merupakan tahap lanjutan dengan keputusan biaya dan pengukuran beban.
Rancangan ini tidak memasang backend recruitment, mengubah DNS, memakai database produksi bersama, atau menjalankan benchmark pada layanan aktif. Halaman blueprint statis dipublikasikan terpisah dari deployment aplikasi.