80/20 Of The Week: Web Servers (Apache, Nginx, Tomcat, ...)

80/20 Of The Week … Web Servers (Apache, Nginx, Tomcat, …)

When we build backend apps, we usually talk about frameworks. Spring Boot, ASP.NET Core, Django, Express and so on. And we mostly care about that cos that is where we write the actual application logic. Controllers, routes, services, validation, database calls, authentication and what not. But the framework itself is not the whole story. At some point, an HTTP request has to arrive from the outside world and something needs to accept it, parse it, route it and give the application a chance to respond. That is where web servers enter the picture.

The basic idea A web server is the layer that receives HTTP requests and returns HTTP responses. Depending on the setup, it can:

serve static files
forward requests to backend apps
handle TLS/HTTPS
compress responses
cache content
route traffic
load balance across multiple app instances

So when we say “server”, we need to be careful.Sometimes we mean the machine. Sometimes we mean the application process. Sometimes we mean software like Nginx, Apache HTTP Server or Tomcat.

The OG style In older Java web deployments, the server often existed first.You would install something like Tomcat separately. Then you would build your Java application as a .war file and deploy it into that Tomcat server.

So the flow was basically: Tomcat starts your app is deployed into Tomcat Tomcat receives requests Tomcat passes them to your Java web app In that model: server starts the app

The Spring Boot style Spring Boot made this feel different. Instead of installing Tomcat separately and deploying a WAR file, you usually build a runnable JAR. Then you run:

java -jar app.jar

and the app starts its own embedded server.

Most commonly that is embedded Tomcat, but it does not have to be only Tomcat.

The important shift is: app starts the server

That is why Spring Boot apps feel easier to run and deploy cos server is packaged with the application.

Can Spring work without Tomcat? Yes, but it still needs some kind of web server/runtime if it wants to serve HTTP requests. For a regular Spring MVC app, Tomcat is the common default. But Spring Boot can also use alternatives like Jetty or Undertow. For reactive apps, Netty is also common.

So the point is not:

Spring = Tomcat forever

The point is: Spring needs something that can accept HTTP requests and connect them to the application. Tomcat is just the most common example people see first.

Where Apache and Nginx fit Apache HTTP Server and Nginx are usually a different layer. They often sit in front of your backend app. For example:

Client → Nginx / Apache HTTP Server → Spring Boot app on port 8080

In that setup, Nginx or Apache can handle things like:

HTTPS
static files
reverse proxying
routing
compression
load balancing
forwarding traffic to multiple app instances

So Nginx is not only a load balancer.

It can be a web server, reverse proxy, cache and load balancer depending on how you use it.

How it looks in practice

A simple embedded setup:

Client → Spring Boot JAR → embedded Tomcat → DispatcherServlet → Controller → Service → Database

A more production-like setup:

Client → Nginx / Apache → Spring Boot instance 1 → Spring Boot instance 2 → Spring Boot instance 3

Here the front server acts as the entry point.

The app servers run the business logic.

Main takeaway Frameworks help us build the application. Web servers help expose that application to the network. Embedded server means: the app starts the server External server means: the server starts the app Reverse proxy means: something sits in front and forwards traffic to the app That is why modern backend deployment is not just about writing controllers. It is also about understanding what actually receives the request before your code ever runs.

#Backend #SpringBoot #Java #WebServers #Tomcat #Nginx #Apache #SystemDesign

Web Servers