Project: Spring Boot Permit Service Boundaries

Last updated: 5 Oct 202610 min read

project

Build a Spring Boot permit service for reviewer 47, reviewer 81, and private permit 62. The filter chain admits authenticated reviewers to private routes, while a service checks assignment for the exact permit. An approval request carries only operation ID, expected revision, and bounded reason. A reviewer-scoped repository query returns at most 47 permit cards with district labels and attachment counts; it must not load every attachment. The approval transaction checks current assignment and revision, commits one case result, one operation outcome, and one pending outbox event. A dropped response can be retried under the same operation ID, and a crashed queue hint cannot erase the pending event.

Build contract

Enable method security if an annotated service method is part of the permission boundary; test the proxy path.
Bind a narrow validated command DTO, then map malformed, forbidden, missing, and stale requests separately.
Apply assignment scope in SQL before paging, fetch only displayed district data, and make cursor order stable.
Protect the case transition with a database concurrency rule and a unique logical operation identity.
Commit outbox intent with the case, then run a relay that can recover a lost after-commit wake-up.

Implementation checkpoint

public class SpringPermitCheckpoint {
  static boolean shouldApply(long expectedRevision, long currentRevision) {
    return expectedRevision == currentRevision;
  }

  public static void main(String[] args) {
    System.out.println(shouldApply(5, 6));
    System.out.println(shouldApply(6, 6));
  }
}

Cost and boundaries

A reviewer-scoped detail read adds an indexed assignment check but prevents a valid account from reading every case. A bounded JPA page limits parent materialization to its chosen width; district prefetch removes per-row lazy reads, while attachment aggregation avoids loading a large child collection. A Page count query may add database work when the UI needs only next-page continuation. The approval transaction holds a lock or resolves an optimistic conflict for one case, so keep provider calls outside it. Unique operation and outbox rows add storage and writes but make ambiguous retries and lost notifications inspectable. Measure SQL count, rows read, lock wait, pending-event age, and p95 latency against a representative database.

Failure drill

Request permit 62 as reviewer 81 despite the broad reviewer role; no private field may appear. Invoke a guarded method through a Spring bean and then by same-bean self-call to expose the proxy boundary. Submit a blank reason, extra status field, stale revision, and an unassigned reviewer; each must have the expected distinct outcome. Give one permit 620 attachments and inspect response allocations while paging through timestamp ties. Race two exact approval retries, drop a successful HTTP response, and reuse the ID with a changed reason. Raise before commit and verify both case and outbox rollback. Then commit and kill the web process before queue wake-up; the independent relay must find the pending event.

Acceptance checks

Reviewer role alone never grants permit 62 to reviewer 81.
Invalid shape, forbidden access, missing case, and stale revision have deliberate distinct handling.
The queue stays bounded without district N+1 reads or attachment hydration.
One logical approval yields one committed result and one durable notification intent.

Common Mistakes

Assuming every annotated self-call is intercepted.
Binding a request directly to a persistence entity.
Filtering the reviewer queue only after pagination.
Equating after-commit notification with a durable outbox.

web-tech

web-development