Current architecture
Understand transaction processing, control data and the institutional deployment boundary.
#Transaction data flow
Institution service + SDK → Sigillum acceptance and processing → application-layer sealed package → Kafka → ClickHouse.
The SDK propagates actual execution context. Processing evaluates relationships and completion. Sealed transaction packages move through Kafka to persistence. ClickHouse supports transaction and step queries. Acceptance receipts and sealed records ready for review represent different stages.
#Control data and transaction data
Institution, user, environment, application, service and connection definitions belong to the control plane. The current installation may use PostgreSQL for these definitions. ClickHouse stores transaction traces and sealed packages. Kafka is a transport layer, not an archive or a final-storage measurement.
#Institutional boundary
Access, certificates, keys and source permissions for the installed product are managed within the institution’s environment. This public website does not receive transactions. Documentation search runs locally in the browser. Example hostnames are not customer endpoints.
#Measure capacity with representative workloads
Compression depends on steps per transaction, payload repetition, partitioning, part counts and hardware. No fixed saving percentage, universal 50 ms query time or unlimited traffic on a particular server is implied.