Unidirectional vs Bidirectional JPA Relationships

The difference comes down to navigation direction. In a unidirectional relationship only one entity has a reference to the other. For example, Order has a customer field, but Customer doesn't have an orders list. You can go from an order to its customer in your Java code, but not the other way round.

In a bidirectional relationship, both entities reference each other. Order has customer, and Customer has a list of orders. That lets you navigate from either side, which is handy when you need it. But it comes with a cost. You have to use the mappedBy attribute on the non-owning side to tell JPA which side controls the foreign key, and you have to keep both sides synchronized in your code. If you add an order to the customer's list but forget to set the customer on the order, things get inconsistent.

There's also a big pitfall with bidirectional relationships: infinite loops during JSON serialization. If you return a Customer entity straight from a REST controller, Jackson serializes the orders list, each order references the customer again, and it loops forever and throws a stack overflow. You fix that with JSON annotations like JsonManagedReference and JsonBackReference, or JsonIgnore, or better yet by returning a DTO instead of the entity.

My rule is to start unidirectional by default, because it's simpler and safer, and only go bidirectional when I genuinely need to navigate from both sides — and then handle the synchronization and the JSON serialization carefully.