You need a durable audit trail of every change to a set of entities: who changed what, with old and new values. Compare building it on JPA lifecycle callbacks, on Hibernate Envers, and on database triggers.

## Start by pinning the requirement 'Audit trail' hides three very different requirements, and the right answer differs for each: 1. **Operational forensics** — 'who last touched this record and when'. Weak completeness is acceptable. 2. **Business history** — 'show me this contract as it stood in March'. Needs old values and time travel, but only for writes the application makes. 3. **Compliance evidence** — 'prove no change escaped the log'. Needs completeness against every writer, including a DBA at a console. Interviewers asking this want to see you separate these before choosing a mechanism. ## Option 1: lifecycle callbacks and listeners An `@EntityListeners` class stamping `updatedBy`/`updatedAt`, or writing rows to an audit table. *Strengths*: trivial to build, portable JPA, and it sits in application code where the current user is available (typically from a thread-local populated at the request edge). Fully under your control in shape and volume. *Weaknesses*: a `@PreUpdate` sees only the entity's current values, so producing a diff means capturing a snapshot in `@PostLoad` and comparing, or dropping to Hibernate's `Interceptor.onFlushDirty` with its `previousState` array. Callbacks must not use the `EntityManager`, so writing the audit row from inside one is unsupported — you accumulate records and write them from the service layer or a transaction synchronisation. And the coverage holes are permanent: bulk JPQL `update`/`delete`, native SQL, external writers, changes confined to an inverse-side collection, and setters that write an identical value. ## Option 2: Hibernate Envers `@Audited` on an entity makes Hibernate maintain a parallel `<table>_AUD` table with a revision number and revision-type column, plus a `REVINFO` revision entity you can extend to carry the user and any custom metadata. `AuditReader` queries history, reconstructs an entity at a revision, and lists revisions where a given property changed. *Strengths*: old and new values without writing diff code, transactionally consistent with the change, a real query API, and configurable strategies (validity-audit strategy adds end-revision columns to make 'as of' queries fast at the cost of extra writes). *Weaknesses*: table count and storage roughly double, and audit tables usually grow faster than the originals; write latency increases; schema evolution now has two tables to migrate and historical rows recorded under old shapes; querying history at scale needs its own indexing thought. Most importantly it hooks Hibernate's event system, so it inherits exactly the same blindness as callbacks to bulk DML, native SQL and non-application writers. Envers solves the *fidelity* problem, not the *coverage* problem. ## Option 3: database triggers (or engine-level change capture) AFTER INSERT/UPDATE/DELETE triggers writing to a history table, or logical decoding / change-data-capture off the transaction log. *Strengths*: complete. Every write is captured regardless of its origin — your application, another service, a migration, a person at a console. Old and new row images are available natively. It cannot be bypassed by anyone using the database normally. *Weaknesses*: written in a database-specific language, living outside the application repository unless you are disciplined about migrations owning them; invisible to application developers, so 'why is this insert slow' becomes a hunt; harder to unit test; and they have no idea who the application user is. The standard remedy is to set a session-local variable (`SET LOCAL app.user_id = ...`) at the start of each transaction and have the trigger read it — which means the ORM path must reliably set it, and any writer that forgets produces rows with no attribution. Log-based capture avoids the write-path cost but adds a pipeline to operate and is eventually consistent. ## A defensible recommendation - Requirement 1 (forensics): listener-stamped `updatedBy`/`updatedAt` columns. Cheap, good enough, and honest about being best-effort. - Requirement 2 (business history): Envers, or a hand-rolled history table fed by an `Interceptor` if you want control over shape and retention. Pair it with a written rule that bulk DML on audited entities is prohibited, and enforce it in review — because the mechanism cannot enforce it for you. - Requirement 3 (compliance): trigger-based or log-based capture as the source of truth, with the application pushing user identity into a session variable so the captured rows carry context. Application-side auditing then becomes an enrichment layer, not the evidence. ## The judgement to voice The interesting sentence is not 'which tool' but 'what guarantee'. Any ORM-level mechanism can only see writes that go through the ORM, so the strength of an ORM audit trail is a property of your write-path discipline, not of the tool. If the organisation cannot promise that every write goes through the application, no amount of `@Audited` will make the trail complete, and saying so is the senior answer. Add retention and cost: audit data outlives operational data, usually needs partitioning or archival, and is often the largest table in the system within a year.