Apache · Configuration and operations
How does Apache's request processing architecture work?
Short answer
Apache runs a parent process that manages child processes or threads. Each connection passes through a multi-phase request pipeline where modules can inspect or modify the request before a handler produces the response.
A root-owned parent process reads configuration, binds ports and manages children. It does not serve requests itself. Depending on the MPM, children are either processes with a single thread, processes with many threads, or processes with asynchronous connection handling plus worker threads.
Once a connection is accepted, Apache processes it through phases: post-read, URI translation, header parsing, access control, authentication, authorization, type checking, fixups, response handling and logging. Modules hook into these phases, which is why enabling a module can change behaviour without touching application code.
ServerRoot "/etc/apache2"
Listen 80
ServerName www.example.com
LoadModule mpm_event_module modules/mod_mpm_event.so
ErrorLog /var/log/apache2/error.log
LogLevel warn
IncludeOptional sites-enabled/*.confPractical consequences
- The parent can reload configuration while old children finish in-flight requests
- Per-request work is spread across child processes and threads, not one shared event loop
- Modules are loaded into the server process and must be compatible with the chosen MPM
- A crash in a child is isolated, but a crash in the parent takes down the service
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is the role of the parent process?
- 2How does the request pipeline affect module behaviour?
- 3Why can a module force a particular MPM?
- 4What happens to in-flight requests during a graceful restart?
Say it in the interview
Apache uses a parent process that owns configuration and supervises children. Children accept connections and run each request through a module-driven pipeline covering URI mapping, access checks, auth and response generation. The MPM decides whether concurrency comes from processes, threads or event-driven handling. That model is why graceful reloads can replace workers without dropping active requests.
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.