For a Spring Boot backend heading into 2027, my review checklist starts with authorization, transaction boundaries, concurrent requests, and recovery after partial failure.

I'm Youssef Saoud, a Java backend developer building Orqestra, a project and vendor management application using Spring Boot, Angular, and PostgreSQL. These are the questions I would bring to a backend review as I plan further work on the project.

The year is a planning horizon. The engineering problems already exist today.

1. Can a request change its own privileges?

Consider an employee accepting an invitation. The request should provide the password needed to finish registration. It should not be trusted to choose the account's role or replace the invited email address.

In Orqestra, acceptance constructs the account from the invitation's stored identity and role. Administrative invitation operations have an administrator permission check.

Review question: Which values come from an authenticated identity or trusted database record, and which come from the caller?

The integration tests include an acceptance payload that attempts to supply an administrator role and a different email. The resulting account must still use the invitation's stored values.

2. What happens when two requests arrive together?

Checking that an invitation is pending is insufficient if two requests can both observe that state before either updates it.

Orqestra's acceptance transaction obtains a pessimistic write lock on the invitation row. It then validates the invitation, creates the account, and marks the invitation accepted within the transaction.

Review question: What coordinates competing attempts to perform the same state transition?

@Transactional defines the unit of work, but the concurrency strategy still needs to be explicit. Locking also has costs: this implementation performs password hashing while the transaction is open, which deserves measurement as traffic grows.

3. Where does the database transaction stop?

An SMTP server does not participate in the application's PostgreSQL transaction. Saving an invitation and submitting an email are separate operations with separate failure modes.

Orqestra commits the invitation before submitting the email, then records the delivery outcome separately. Failed submission leaves an invitation that an administrator can resend.

Review question: If the external call fails after the database commits, what state remains, and who can recover it?

A successful SMTP submission also does not establish inbox delivery.

4. Can an old result overwrite newer state?

Resending an invitation rotates its token. An earlier email attempt might finish after a newer resend.

The delivery result is associated with the token hash for that attempt. Orqestra applies the result only when that hash still matches the invitation's current hash.

Review question: Does an asynchronous result identify the version of the work it belongs to?

This check protects the current delivery status from a superseded attempt. It does not cancel an email already submitted to a provider.

5. What does the test actually prove?

The invitation tests cover expiry, revocation, reuse, role preservation, token rotation, and failed-delivery retries. A focused concurrency test starts two acceptance attempts and checks that one succeeds and one account exists.

Email delivery is mocked. These tests exercise application behavior around delivery outcomes, rather than real provider delivery or production load.

Review question: Which guarantee is tested, and which assumption still needs operational evidence?

My next improvement

There is still a crash window between committing an invitation and submitting its email. A transactional outbox is a candidate improvement: persist a delivery job alongside the invitation change, then let a worker handle delivery and retries.

That work would need its own rules for duplicate attempts, superseded tokens, and worker failures. It is a proposed improvement, not an implemented guarantee.

For my 2027 work, these questions give each feature a concrete review standard: permissions, competing requests, external failures, stale results, and evidence.

You can inspect the invitation implementation and tests and follow my work on GitHub or LinkedIn.