Explain the architecture of your project and the technical decisions you made.
Fast recall
Quick revision
Core answer
Ability to think in systems and justify technical decisions—not just whether you used a framework, but why you chose it over alternatives
Listing technologies like a resume—'I used Spring Boot, MySQL, and React'—without explaining the reasoning or the problems they solved in your context
Acknowledge trade-offs explicitly—'I chose MySQL for ACID guarantees on transactions, but PostgreSQL would have given better JSON support for audit logs'
Interview-ready guide
Interview answer
My project follows a three-layer architecture built with Spring Boot.
At the top is the presentation layer, which has REST controllers handling HTTP requests.
For example, OrderController receives a POST request to create an order, validates the input using Bean Validation, and delegates to the service layer. I chose Spring MVC because it handles all the JSON serialization and exception mapping automatically. The middle layer is the service layer, where business logic lives.
OrderService doesn't just save data—it coordinates multiple operations like checking inventory, applying discounts, and creating order records. I use the at-Transactional annotation here to ensure all these steps succeed or fail together atomically. This layer makes the business rules testable without needing HTTP or a database.
The bottom layer is persistence, using Spring Data JPA. OrderRepository extends JpaRepository, which gives me standard CRUD methods without writing SQL. For complex queries, I use method naming conventions or JPQL.
I chose MySQL as the database because I needed ACID transactions—orders and inventory updates must be consistent. I compared PostgreSQL and MySQL against the relational model and features I needed. Both could support the project, so team familiarity and the available environment made MySQL the practical choice.
The entire app is packaged as a single JAR with an embedded Tomcat server, so deployment is just running java -jar. The stateless application tier can run on several instances, while the shared database preserves durable state. If load grows, I would measure the bottleneck first: it may call for a query or index change, more application capacity, carefully designed caching, or a database change.
I'd also externalize configuration to environment variables instead of hardcoding database URLs. But for the scope of my project, this three-layer monolith was the right balance of simplicity and structure.
Explain the architecture of your project and the technical decisions you made.
Direct Answer
Describe your system in layers: presentation layer with controllers handling HTTP requests and returning JSON, service layer containing business logic and transaction management, and persistence layer with repositories accessing the database. Explain why you chose each technology—Spring Boot for dependency injection, MySQL for relational data, and what trade-offs you accepted.
Code Example
// PRESENTATION LAYER: Handles HTTP, delegates to services
@RestController
@RequestMapping("/api/orders")
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping
public ResponseEntity<OrderResponse> createOrder(@RequestBody OrderRequest req) {
var order = orderService.processOrder(req);
return ResponseEntity.status(201).body(new OrderResponse(order));
}
}
// SERVICE LAYER: Business logic and transaction boundaries
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepo;
@Autowired
private InventoryService inventoryService;
@Transactional // Ensures atomicity across multiple operations
public Order processOrder(OrderRequest req) {
inventoryService.reserveStock(req.productId(), req.quantity());
var order = new Order(req.productId(), req.quantity());
return orderRepo.save(order);
}
}
// PERSISTENCE LAYER: Data access abstraction
@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
List<Order> findByCustomerId(Long customerId);
}
// In your answer: "This separation lets me test business logic
// without starting a web server, and keep persistence details out of
// controllers; a database change can still affect mappings and behaviour."
Common Mistakes & Pitfalls
- Technology Resume: Listing 'Spring Boot, MySQL, React, Docker' without explaining why you chose each or how they interact shows you're reciting a stack, not thinking architecturally.
- No Justification: Saying 'I used Spring Boot' without explaining the benefits—dependency injection, embedded server, auto-configuration—suggests you followed a tutorial blindly.
- Missing Trade-offs: Claiming 'MySQL is the best choice' without acknowledging any downsides—rigid schema, scaling complexity—shows you don't understand trade-offs. Every technology has costs.
- Overengineering Claims: Saying 'I used microservices with Kafka' for a student project with 3 entities raises red flags. Interviewers will probe deeper and expose gaps. Stick to what you genuinely built and understood.
- No Reasoning: 'I used JWT because everyone uses it' is weak. Explain: 'I used JWT because it's stateless, so I didn't need server-side session storage, which simplified deployment.'
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.