The Real Estate API is a public backend implementation for property operations. Its build configuration specifies Java 26 and Spring Boot 4.1.1, with PostgreSQL, Redis and S3-related dependencies.
This article examines concrete source-level decisions. It does not claim a verified commercial migration, production traffic or incidents in a previous system.
Make dependency direction inspectable
The project separates domain, application and infrastructure code. Its ArchitectureTest reads Java source and checks imports and prohibited dependency strings.
That is a JUnit source-level check, not an ArchUnit test or a Java compiler guarantee. It can catch specified boundary violations, but its coverage is limited to the rules it implements. Domain invariants also need behavioral tests.
A language or framework does not create these boundaries automatically. Express and Prisma can also support explicit request models, transactions and modular design.
Registration assigns the public role internally
The authentication service rejects a requested registration role other than USER and creates the user with that role. This is a concrete defense against trusting a public request to assign privileged access.
The corresponding tests should include an attempted privileged role, missing fields and valid registration. Response mapping deserves a separate check so internal fields are not accidentally exposed.
Refresh sessions are database-backed
The reviewed session adapter uses JPA and an EntityManager. It is not a Redis session-tree implementation.
The refresh service locks the user and session, verifies identity and token fingerprints, issues a replacement and revokes the old session. Reuse of a revoked token triggers family revocation. Family revocation should not be described as automatically revoking every session on the account; the code also has a separate user-wide path.
A useful detail is noRollbackFor on the replay exception. The intended revocation must survive that exception rather than being undone with the failed refresh. This deserves an integration test using the real transaction boundary.
Spring's transaction documentation explains proxy behavior, including the limits of self-invocation. An annotation alone is not evidence that every call participates in the intended transaction.
Storage behavior must match the article
The S3 adapter uploads bytes through a server-side PutObject call. It creates signed GET URLs with a five-minute duration for downloads.
That differs from a browser uploading through a fifteen-minute presigned PUT URL. Authorization, size limits, content validation and private bucket settings remain separate concerns that need implementation and deployment checks.
What the source demonstrates
The repository provides inspectable choices around boundaries, session rotation and storage. A thorough validation would exercise concurrent refresh, replay revocation, cross-user access, transaction rollback and unavailable storage.
Those checks were not run as part of this article review. The useful takeaway is how to connect each claimed property to source and executable evidence, rather than promising that choosing Spring Boot eliminates data or security defects.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
