Server-Side Logic: Architecting the Brain
In an interview, junior developers focus entirely on making the code work. Senior developers focus on where the code lives and how it fails. The backend is the authoritative brain of any software project. It enforces the rules of the business, processes raw data, and guarantees that every action strictly follows the defined system constraints.
When asked to build a backend feature on the whiteboard, writing a single, massive function that handles the HTTP route, queries the database, and formats the response is an immediate red flag. You must demonstrate that you understand how to separate concerns and isolate logic.
Separation of Concerns: Controllers, Services, and Data
Professional backend architecture isolates different types of logic into distinct layers. Mixing HTTP request handling, database queries, and business rules in a single file makes the code impossible to test and reuse.
When explaining your server-side architecture to an interviewer, break it down into these three tiers:
- Controllers (The Traffic Directors): Explain that controllers receive the incoming HTTP request, extract the necessary parameters, and return the final HTTP response. Emphasize strongly that they should contain zero business logic.
- Services (The Business Rules): Describe this as the layer where the actual work happens, such as calculating totals or checking inventory. Highlight that services are completely agnostic of HTTP, which makes them easy to test or trigger from background jobs.
- Data Access Layer (The Database Interface): Explain that this layer interacts directly with the database, abstracting the SQL queries or Object-Relational Mapping (ORM) methods away from the service layer.
Here is the visual explanation of the layers, with an example:
Middleware: The Protective Barrier
Interviewers often ask how you handle cross-cutting concerns like authentication, logging, or error handling. The answer is middleware.
Describe middleware as a protective barrier that intercepts the request before it ever reaches the core business logic. You can demonstrate this by explaining how you use middleware for authorization to enforce access control , or how all routes pass their unhandled exceptions down to a single centralized error-handling middleware function located at the very end of the request pipeline.
/**
* Example of discussing Layered Architecture in an interview.
* By keeping the Controller thin, you prove that your Service
* logic can be reused by a background worker or a CLI tool.
*/
// 1. The Controller (Only handles HTTP)
const createOrderController = async (req, res, next) => {
try {
const orderData = req.body;
// Handoff to the service layer
const newOrder = await OrderService.processNewOrder(orderData, req.user.id);
return res.status(201).json({ status: 'success', data: newOrder });
} catch (error) {
next(error); // Pass to centralized error middleware
}
};
// 2. The Service (Only handles Business Logic)
const processNewOrder = async (orderData, userId) => {
// Logic is completely unaware of HTTP requests or responses
const inventoryCheck = await InventoryLayer.checkStock(orderData.items);
if (!inventoryCheck) throw new Error("Insufficient stock");
return await DatabaseLayer.insertOrder(orderData, userId);
};
Managing Asynchronous Processing (Background Jobs)
A classic interview question is: “How would you design an API endpoint to generate a massive PDF report?” If you say you would generate the PDF directly in the controller and return it to the user, you fail the scale test.
Not all logic should execute during the standard HTTP request lifecycle. If a task takes longer than a few hundred milliseconds, it will block the client and degrade the user experience. To pass this prompt, you must introduce asynchronous processing:
- Message Queues: Explain how systems like RabbitMQ or Redis allow the main server to offload heavy tasks. Describe the flow: The server instantly returns a “202 Accepted” status to the client, while a separate worker process pulls the task from the queue and handles the actual job in the background.
- Cron Jobs: Mention these for scheduled tasks that run at specific intervals, such as generating weekly financial reports or clearing expired authentication sessions from the database.
- Webhooks: Suggest using asynchronous callbacks to notify other systems when a specific event occurs, such as alerting an inventory system after a successful payment transaction.
Learning Point: When an interviewer asks a systems question, they are testing your empathy for the server’s resources. By immediately suggesting a message queue for heavy tasks, you prove that you know how to protect the main API application from buckling under unexpected, compute-heavy traffic.
Popular Guides