Introduction

Most developers learn:

@Entity

@Repository

save()

findById()

But production systems fail because of:

N+1 Queries

Memory Leaks

Deadlocks

Slow Queries

Long Transactions

Improper Fetching

Missing Indexes

This guide covers the best practices used in:

Banking Systems

Insurance Applications

E-Commerce Platforms

Financial Services

Large Enterprise Applications

---

Production Architecture Overview

flowchart TD

A["Controller"]

B["Service"]

C["Repository"]

D["Hibernate"]

E["Database"]

F["Redis Cache"]

G["Monitoring"]

A --> B
B --> C
C --> D
D --> E

D --> F

D --> G

---

Rule #1: Always Use LAZY Loading

---

Bad

@ManyToOne(fetch = FetchType.EAGER)
private Department department;

Problem:

Every Employee Load
       ↓
Department Loaded
       ↓
Unnecessary Queries

---

Good

@ManyToOne(fetch = FetchType.LAZY)
private Department department;

---

Fetch Strategy Rule

Default = LAZY

Use JOIN FETCH
When Data Is Needed

---

Production Example

Insurance Policy API

Policy
Customer
Address
Beneficiaries
Claims

Using EAGER:

50 Queries

Using LAZY + Fetch Join:

2 Queries

---

Rule #2: Never Return Entities from REST APIs

---

Bad

@GetMapping("/{id}")
public Employee getEmployee(
        @PathVariable Long id
) {
    return repository.findById(id).orElseThrow();
}

Problems:

Lazy Loading Exceptions

Infinite JSON Recursion

Large Payloads

Security Risks

---

Good

DTO

public record EmployeeResponse(
        Long id,
        String name,
        String department
) {
}

Service:

public EmployeeResponse getEmployee(Long id) {

    Employee employee =
            repository.findById(id)
                    .orElseThrow();

    return new EmployeeResponse(
            employee.getId(),
            employee.getName(),
            employee.getDepartment().getName()
    );
}

---

Entity vs DTO Diagram

flowchart LR

A["Entity"]

B["Sensitive Fields"]

C["DTO"]

D["Only Required Data"]

A --> B

A --> C

C --> D

---

Rule #3: Always Fix N+1 Queries

Biggest production issue.

---

Bad

List<Employee> employees =
        repository.findAll();

employees.forEach(
        e -> e.getDepartment().getName()
);

Queries:

1 + N Queries

---

Good

@Query("""
       select e
       from Employee e
       join fetch e.department
       """)
List<Employee> findAllWithDepartment();

---

N+1 Production Impact

Before

3000 Queries

Response 12 sec

----------------

After

1 Query

Response 300 ms

---

Rule #4: Always Use Pagination

---

Never Do This

repository.findAll();

On:

5 Million Records

---

Use

Page<Employee> findByStatus(
        String status,
        Pageable pageable
);

---

Example

PageRequest.of(
        0,
        50
);

---

Pagination Flow

flowchart TD

A["5 Million Rows"]

B["findAll"]

C["OOM Risk"]

D["Page Size 50"]

E["Fast"]

A --> B
B --> C

A --> D
D --> E

---

Rule #5: Use DTO Projection for Read APIs

---

Bad

List<Employee> employees =
        repository.findAll();

Loads:

Name

Salary

Address

Manager

Projects

Audit Data

---

Good

public record EmployeeSummary(
        String name,
        Double salary
) {
}

@Query("""
       select new com.codewithvenu.dto.EmployeeSummary(
           e.name,
           e.salary
       )
       from Employee e
       """)

---

Rule #6: Add Proper Indexes

Most performance issues are database problems.

---

Example

SELECT *
FROM employees
WHERE email = ?;

Without index:

Full Table Scan

---

Good

CREATE INDEX idx_email
ON employees(email);

---

Common Indexes

email

account_number

customer_id

status

created_date

policy_number

---

Rule #7: Keep Transactions Small

---

Bad

@Transactional
public void processClaim() {

    saveClaim();

    callExternalApi();

    sendEmail();

    generatePdf();
}

Transaction remains open.

---

Good

@Transactional
public void saveClaim() {
}

External work outside transaction.

---

Transaction Design

flowchart TD

A["Open Transaction"]

B["DB Work"]

C["Commit"]

D["External API"]

A --> B
B --> C
C --> D

---

Rule #8: Use Read-Only Transactions

---

Bad

@Transactional
public List<Employee> getEmployees() {
}

---

Good

@Transactional(readOnly = true)
public List<Employee> getEmployees() {
}

Benefits:

Less Dirty Checking

Better Performance

---

Rule #9: Disable Open Session In View

---

Bad

spring:
  jpa:
    open-in-view: true

Problem:

Unexpected Queries

Memory Usage

N+1 Hidden Issues

---

Good

spring:
  jpa:
    open-in-view: false

---

Rule #10: Use Batch Processing for Large Data

---

Bad

for(Employee e : employees){

    repository.save(e);
}

100,000 records:

Huge Memory Usage

---

Good

if(i % 50 == 0){

    entityManager.flush();
    entityManager.clear();
}

---

Batch Diagram

flowchart TD

A["50 Records"]

B["flush"]

C["clear"]

D["Next 50"]

A --> B
B --> C
C --> D

---

Rule #11: Use Optimistic Locking by Default

---

Entity

@Version
private Integer version;

Benefits:

Detect Lost Updates

Prevent Data Corruption

---

Optimistic Locking Flow

flowchart TD

A["Version 1"]

B["User A Update"]

C["Version 2"]

D["User B Update"]

E["Version Conflict"]

A --> B
B --> C
C --> D
D --> E

---

Rule #12: Use Pessimistic Locking Only When Needed

Use for:

Seat Booking

Inventory

Money Transfer

Avoid:

Simple CRUD APIs

---

Rule #13: Cache Read Heavy Data

Good candidates:

Countries

States

Currencies

Configuration Tables

---

Example

@Entity
@Cacheable
@Cache(
    usage = CacheConcurrencyStrategy.READ_ONLY
)
public class Country {
}

---

Rule #14: Avoid CascadeType.ALL Everywhere

---

Bad

@OneToMany(
        cascade = CascadeType.ALL
)

Danger:

Unexpected Deletes

---

Better

cascade = {
        CascadeType.PERSIST,
        CascadeType.MERGE
}

Use only required cascades.

---

Rule #15: Use Fetch Join Carefully

Bad:

join fetch employee.projects
join fetch employee.tasks
join fetch employee.comments

Problem:

Cartesian Explosion

Huge result sets.

---

Rule #16: Monitor SQL Queries

Enable:

logging:
  level:
    org.hibernate.SQL: DEBUG

Monitor:

Query Count

Slow Queries

Execution Time

---

Production Monitoring Stack

Datadog

Dynatrace

Grafana

Prometheus

Splunk

ELK

---

Rule #17: Never Use findAll() in Large Tables

Bad:

repository.findAll();

Production outage waiting to happen.

Always ask:

How Many Rows Exist?

---

Rule #18: Use Separate Read and Write APIs

Example:

Read API
     ↓
Projection

Write API
     ↓
Entity

Improves performance.

---

Rule #19: Use Database Constraints

Never rely only on Java validation.

---

Example

ALTER TABLE employees
ADD CONSTRAINT uk_email
UNIQUE(email);

---

Rule #20: Handle Exceptions Properly

Bad:

catch(Exception e){
}

---

Good:

catch(DataIntegrityViolationException ex){
}

Handle specific exceptions.

---

Rule #21: Use Connection Pooling

Use:

HikariCP

Default in Spring Boot.

---

Recommended Settings

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5

---

Rule #22: Use Proper Isolation Levels

Default:

@Transactional

High consistency:

@Transactional(
        isolation =
        Isolation.REPEATABLE_READ
)

Use carefully.

---

Rule #23: Avoid Long Entity Graphs

Bad:

Employee

Department

Manager

Projects

Tasks

Comments

Files

Attachments

Loading everything:

Slow

Use DTOs.

---

Rule #24: Soft Delete for Business Data

Instead of:

DELETE FROM customer;

Use:

status='INACTIVE'

Benefits:

Audit

Recovery

Compliance

---

Rule #25: Database Migration Tools

Never modify production schema manually.

Use:

Flyway

Liquibase

---

Production Deployment Flow

flowchart TD

A["Code"]

B["Flyway Migration"]

C["Application Deploy"]

D["Database Updated"]

A --> B
B --> C
C --> D

---

Real Banking Example

Money Transfer API

Problems:

Deadlocks

Long Transactions

Missing Indexes

N+1 Queries

Fixes:

Optimistic Locking

Proper Indexes

DTO Projection

Pagination

Short Transactions

Result:

7 sec
↓
250 ms

---

Production Readiness Checklist

flowchart TD

A["Production Release"]

B["Pagination"]

C["Indexes"]

D["DTO"]

E["Caching"]

F["Transactions"]

G["Monitoring"]

H["Security"]

I["Ready"]

A --> B
A --> C
A --> D
A --> E
A --> F
A --> G
A --> H

B --> I
C --> I
D --> I
E --> I
F --> I
G --> I
H --> I

---

Top Production Mistakes

❌ EAGER Loading Everywhere

❌ findAll() On Large Tables

❌ No Pagination

❌ No DTOs

❌ No Indexes

❌ Long Transactions

❌ CascadeType.ALL Everywhere

❌ No Monitoring

❌ No Batch Processing

❌ Ignoring N+1 Queries

---

Architect Interview Questions

Q1. What are your top JPA production rules?

LAZY Loading

Pagination

DTO Projection

Indexes

Batch Processing

Caching

Short Transactions

---

Q2. Biggest production issue?

N+1 Queries

---

Q3. How do you optimize a slow JPA API?

Check Query Count

Check Indexes

Check Fetch Strategy

Check Pagination

Check DTO Usage

Check Cache

---

Q4. What should never be exposed to REST clients?

Entities

Use DTOs.

---

Final Production Rules

1. Use LAZY Loading

2. Always Use DTOs

3. Fix N+1 Queries

4. Add Proper Indexes

5. Use Pagination

6. Keep Transactions Small

7. Disable OSIV

8. Use Read-Only Transactions

9. Batch Large Operations

10. Monitor SQL Queries

11. Use Optimistic Locking

12. Cache Read-Heavy Data

13. Use Flyway/Liquibase

14. Avoid findAll() On Large Tables

15. Never Return Entities From APIs

---

Summary

Production-grade JPA applications are not built by writing:

repository.save();

repository.findById();

They are built by following:

Performance

Scalability

Reliability

Maintainability

Observability

Golden Formula:

LAZY Loading
+
DTO Projection
+
Pagination
+
Indexes
+
Short Transactions
+
Monitoring
=
Production Ready JPA Application