Spring Boot Interview Questions and Answers with Instant Scoring

In Spring's default proxy-based transaction management, internal method calls bypass the transactional proxy. Consequently, the transaction interceptor is not invoked for that self-invocation. Move the transactional operation into another Spring-managed bean or use an appropriate programmatic transaction mechanism.

REQUIRES_NEW suspends an existing transaction and starts an independent transaction for the invoked operation. Its commit or rollback is independent of the outer transaction. It can require an additional database connection and should be used carefully when many concurrent requests execute nested transactions.

This commonly indicates the N+1 query problem, where related entities are loaded individually during iteration. Investigate SQL logs and Hibernate statistics to identify repeated relationship queries. Use targeted fetch joins, entity graphs, DTO projections, or batching based on the endpoint's data requirements.

Use optimistic locking with a @Version field when conflicts are relatively uncommon. Hibernate includes the version in update checks and detects conflicting modifications. For highly contended operations, evaluate pessimistic locking, atomic database updates, or application-specific concurrency controls.

Process records in bounded batches and periodically flush and clear the persistence context. Enable suitable JDBC batching and avoid unnecessary entity loading or per-record queries. Measure transaction size, database constraints, indexes, and memory usage before selecting the batch size.

readOnly is primarily a transaction hint, not a universal guarantee that database writes are prohibited. With Hibernate, Spring may adjust flush behavior, so automatic persistence of modifications can be suppressed. Do not rely on readOnly as a security boundary; use database permissions for strict write restrictions.

Introduce an idempotency key supplied by the client and persist its processing outcome. Enforce uniqueness atomically so concurrent retries cannot create duplicate operations. Return the previously recorded result for a completed request, while handling in-progress requests and failures explicitly.

A valid signature does not guarantee sufficient authorization. Inspect token issuer, audience, expiration, authority mapping, and endpoint authorization rules. Check whether the authenticated principal has the expected roles or scopes and whether method-level security imposes additional restrictions.

Publish verification keys through a JWKS endpoint and identify signing keys using a key ID in the JWT header. Introduce a new signing key while retaining the old public key for verification during the overlap period. Remove the old key after its issued tokens have expired, accounting for clock skew and verifier cache behavior.

Inspect HikariCP metrics for active, idle, pending, and maximum connections. Look for long-running transactions, leaked connections, slow queries, and connection-pool exhaustion. Compare pool sizing with database connection limits and request concurrency before increasing the pool size.

No. Leak detection reports connections held longer than the configured threshold, including legitimately long operations. Investigate transaction boundaries, query duration, blocking calls, and the reported acquisition stack trace. A later return can indicate a slow operation rather than a permanently leaked connection.

Configure a bounded ThreadPoolTaskExecutor with appropriate core size, maximum size, and queue capacity. Define a rejection policy and apply backpressure or rate limiting when the system reaches capacity. Monitor queue depth, active threads, execution latency, and task failures.

Use the transactional outbox pattern to store the business change and an outgoing event in the same database transaction. A separate publisher transfers committed outbox records to the message broker. Consumers should handle duplicate delivery through idempotent processing because publication may be retried.

Apply connection and response timeouts, bounded retries with backoff, and circuit breakers where appropriate. Use concurrency limits or bulkheads to prevent one failing dependency from consuming all request-processing resources. Only retry operations that are safe to repeat, and monitor failure rates and fallback behavior.

block() waits synchronously and can occupy a Reactor event-loop thread that should remain available for non-blocking work. Under load, this can cause thread starvation, increased latency, or blocking-operation errors. Compose reactive publishers instead, and isolate unavoidable blocking work on an appropriate bounded scheduler.

Compare historical metrics for heap usage, garbage collection, thread counts, connection pools, and response latency. Use thread dumps, heap dumps, profiling, and distributed traces to identify accumulating resources or slow operations. Correlate the degradation with traffic, scheduled jobs, cache growth, and recent deployments.

Transactional tests commonly roll back their changes and may share a transaction across setup and verification steps. This can hide commit-time constraints, flushing behavior, and differences in transaction boundaries. Test explicit commits, separate transactions, and real database behavior when validating production transaction semantics.

Separate liveness from readiness so infrastructure can distinguish an unhealthy process from one temporarily unable to serve traffic. Configure readiness probes to reflect essential startup and service availability conditions without depending on every optional downstream system. Use graceful shutdown and appropriate probe thresholds to reduce failed requests during rolling deployments.