Sari la conținut
gStack

ADR-008 — Stack minimal: fără Kafka și fără Elasticsearch

Acest conținut nu este încă disponibil în limba selectată.

  • Status: Acceptat
  • Data: 2026-07-07
  • Componentă: Arhitectură / infrastructură
  • Decidenți: Arhitect platformă GStack, teamlead

Context

Section titled “Context”

DEV-PLAYBOOK-ul comun (.claude/skills/playbook.md §2) descrie un stack standard care include Kafka ca message broker. Sistemul-frate saas_interdictii folosește în plus Elasticsearch pentru căutare. JDL-ul GRegistry, în schimb, nu declară nici Kafka, nici Elasticsearch — doar PostgreSQL + ehcache. Trebuie consemnat de ce GRegistry diverge de la stack-ul „maximal” al platformei.

Decizie

Section titled “Decizie”

Pentru v1, GRegistry rulează pe un stack minimal: PostgreSQL + ehcache/Hibernate L2, fără broker de mesaje (Kafka) și fără motor de căutare (Elasticsearch).

Motivație:

  • Volum mic, read-heavy. RSI catalogează zeci de sisteme, nu milioane de înregistrări. Interogarea și filtrarea relațională (JPA Criteria + indici PostgreSQL, ADR-006) acoperă complet nevoile de căutare; un motor de căutare full-text ar fi nejustificat.
  • Integrare prin API pull, nu event push. Consumatorii (GPortal, GLog…) citesc registrul la nevoie; nu există (în v1) un flux de evenimente în timp real care să justifice un broker. Redirecționarea auditului către GLog se face prin apel API/log forwarding, nu prin Kafka.
  • Suprafață operațională redusă. Fără Kafka/ES scade complexitatea de deploy, de monitorizare și de securizare — potrivit pentru un serviciu de infrastructură care trebuie să fie foarte stabil.

Alternative considerate

Section titled “Alternative considerate”
  1. Adoptarea integrală a stack-ului din playbook (Kafka + ES). Respins pentru v1: complexitate și cost operațional nejustificate de volum și de tiparul de acces.
  2. Doar Elasticsearch (căutare), fără Kafka. Respins: filtrarea relațională e suficientă; sincronizarea unui index secundar ar adăuga risc de inconsistență.

Consecințe

Section titled “Consecințe”

Pozitive

  • Deploy și operare simple; mai puține puncte de eșec pentru un serviciu critic de catalog.
  • Model de date pur relațional, ușor de raționat și de testat.

Negative / riscuri

  • Dacă în viitor apare nevoia de evenimente în timp real (ex. notificare push când un sistem devine DOWN) sau de căutare full-text avansată, va fi nevoie de un ADR nou care să reintroducă Kafka și/sau Elasticsearch. Acest ADR marchează granița conștient.
  • Divergență documentată față de playbook.md §2 — intenționată, nu o scăpare.

Legături

Section titled “Legături”
  • Model: ../../GRegistry.jdl (fără messageBroker, fără searchEngine)
  • Proces: .claude/skills/playbook.md §2
  • Comparație: ../../../saas_interdictii/CLAUDE.md (folosește Elasticsearch)