Apache · Configuration and operations
How does Apache compare with nginx?
Short answer
Apache is process or thread based with rich per-directory configuration and .htaccess, while nginx is event driven with a smaller config surface. Apache 2.4 event narrows the gap; choose by ecosystem, team skills and workload.
The architectural difference is historical but still relevant. Apache's MPM model gives strong module compatibility and dynamic per-directory configuration. nginx uses a small number of event-driven workers and is very efficient at static files, TLS and proxying. Apache's event MPM removes most of the keep-alive disadvantage.
- Apache: dynamic modules, .htaccess, mature auth and directory features, mod_php legacy support
- nginx: event-driven workers, low memory per connection, strong static and proxy performance
- Apache: configuration can be spread across includes, vhosts and per-directory files
- nginx: configuration is centralized; there is no .htaccess equivalent
- Both support reverse proxying, TLS, HTTP/2, compression and caching
Apache
ProxyPass /api http://127.0.0.1:3000/api
ProxyPassReverse /api http://127.0.0.1:3000/api
nginx
location /api/ {
proxy_pass http://127.0.0.1:3000/api/;
}A common pattern is nginx or a cloud load balancer at the edge for TLS and static assets, with Apache behind it for applications that depend on .htaccess or Apache-specific modules. Running both adds operational complexity, so justify it with a concrete requirement rather than fashion.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When would you choose Apache over nginx?
- 2What does nginx lack that Apache provides?
- 3Does Apache event MPM eliminate nginx's performance advantage?
- 4Why might a team run both?
Say it in the interview
Apache's strength is module compatibility and per-directory configuration, including .htaccess. nginx's strength is a compact event-driven design that is very efficient for static files and proxying. Apache event closes much of the keep-alive gap. I choose based on existing configuration, team skills and whether the app depends on Apache-specific behaviour, then benchmark the real workload.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Apache mock interview and get scored feedback on depth, clarity and confidence.