Generic WorkFlow

The SPA sends POST /records with a bearer access token. The refresh token never touches JavaScript: it lives in an HttpOnly, SameSite=Strict cookie scoped to /auth, and its hash is stored server-side so it can be revoked.

A stateless Spring Security filter verifies the JWT and puts an AuthenticatedUser, including the current workspace, on the request.

RecordService asks one question of one API: does this user hold record:create on this record group? No module reads permission tables directly; they all go through AuthorizationApi.

Owners bypass everything, admins everything except billing actions. Everyone else gets the union of their role's grants and their personal overrides, evaluated by scope against the record-group tree. The user's grants are loaded once into a request-scoped snapshot, so a page full of checks doesn't mean a page full of queries.

Next, the subscription module's PolicyService: is the subscription active, is this record group locked (downgrades lock resources over the new plan's limits), and is the workspace under its MAX_RECORDS_PER_RECORD_GROUP quota for the current period?

Subscription status, entitlements, locked resources and plans sit in four named Redis caches with their own TTLs, so the common case never reaches the database.

Each submitted value is validated and normalised by its FormField definition: TEXT, NUMBER, EMAIL, DATE, SELECT or CURRENCY, with required flags and JSONB-configured rules like min, max and regex. Required fields that are missing fail the whole request.

Values are stored as record_values rows keyed by field, which is what lets a workspace add a column from the UI without anyone writing a migration.

The service publishes a RecordCreatedEvent and increments the period's usage counter in a single SQL UPDATE. Nothing else happens inline.

33 @TransactionalEventListener(AFTER_COMMIT) handlers across the modules react only once the transaction has committed: the activity feed, audit log, dashboards and automations. A rolled-back request can't trigger an email about a record that doesn't exist, and modules stay decoupled, which ModulithStructureTest enforces in the build.

Automations matching the CREATE trigger run next. Each action executor declares how it runs: ADD_NOTE and UPDATE_FIELD are synchronous, SEND_EMAIL is enqueued on the automation-actions Kafka topic so SMTP latency never sits in a user's request.

Every run is logged in automation_logs with a retry count. Failures go to a dead-letter topic, and a scheduler re-runs failed actions every five minutes until they hit their max_retries.

The rest happens on schedules: subscription renewals at 01:00, trash purging and public-link expiry at 02:00, upload clean-up every five minutes, and an outbox poller every minute that confirms pending events and handles retry accounting.