Design patterns used in Spring Boot
Fast recall
Quick revision
Core answer
@Transactional commonly use proxies, JdbcTemplate combines a fixed workflow with callbacks, and application events use Observer-style dispatch. These are implementation examples, not a claim that every Spring bean has one scope or that each class maps to exactly one textbook pattern.Interview-ready guide
Interview answer
Spring uses several pattern ideas together. The application context has registry and factory responsibilities because it reads bean definitions, creates objects, resolves dependencies, and manages scopes. Singleton is the default bean scope, but it is not the scope of every bean. For example, a call from one bean into another bean's @Transactional method normally crosses a Spring proxy that opens and completes the transaction around the target invocation; a self-call can bypass that proxy boundary. JdbcTemplate owns repeated resource and exception workflow while callbacks provide query-specific behavior. Application events are Observer-style dispatch through an event multicaster. These labels explain responsibilities, but the actual Spring contract matters more than forcing each feature into one textbook pattern.
Design patterns used in Spring Boot
Direct Answer
Spring uses many pattern ideas: the container performs factory and registry work, singleton is the default bean scope, AOP features such as @Transactional commonly use proxies, JdbcTemplate combines a fixed workflow with callbacks, and application events use Observer-style dispatch. These are implementation examples, not a claim that every Spring bean has one scope or that each class maps to exactly one textbook pattern.
Code Example
// SINGLETON: Spring creates one instance of this bean
@Service
public class CartService {
private final CartRepository repository; // injected dependency
public CartService(CartRepository repository) {
this.repository = repository; // constructor injection
}
}
// PROXY: @Transactional creates proxy with transaction logic
@Transactional // Spring wraps this method in transaction boundary
public void checkout(Long cartId) {
var cart = repository.findById(cartId).orElseThrow();
// Spring starts transaction before this line
processPayment(cart);
clearCart(cartId);
// Spring commits transaction after this line
}
// OBSERVER: Event publishing and listening
@Component
public class OrderEventPublisher {
private final ApplicationEventPublisher publisher; // injected by Spring
public void notifyOrderPlaced(Order order) {
publisher.publishEvent(new OrderPlacedEvent(order)); // publish
}
}
@EventListener // listens for OrderPlacedEvent
public void sendConfirmationEmail(OrderPlacedEvent event) {
// reacts to event independently
}
Common Mistakes & Pitfalls
- Not recognising patterns in action: Freshers use @Transactional daily but don't realise it's the Proxy pattern — interviewers expect you to make this connection.
- Thinking Spring is the pattern: Saying 'Spring is a Singleton pattern' instead of 'Spring uses Singleton pattern for bean scope' shows confusion between framework and pattern.
- Ignoring why patterns matter: Just listing patterns without explaining how they help (Singleton reduces memory, Proxy adds behavior without code changes) misses the practical value interviewers want to hear.
Check your understanding
Answer these without looking back at the article.
- Why are Spring beans singletons by default?
- How does @Transactional use the Proxy pattern?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.