PHP Backend Developer Top 100 Interview Questions

PHP workers share no memory between requests, so the counters must live in shared storage: a fast cache server, a database table or the web server or gateway in front of PHP. Every request checks and updates the counter atomically.

Common algorithms:

• Fixed window: count requests per key per minute; simple, but allows bursts at window boundaries.
• Sliding window: combine the current and previous windows for smoother limits.
• Token bucket: store tokens and the last refill time, allowing short bursts with a steady average.

Implementation details:

1. Atomic updates: use atomic increment operations, or a single database statement, so concurrent requests cannot both pass when only one should.
2. Keys: per API key, per user or per IP address, with stricter limits on login and password reset.
3. Expiry: counters expire automatically after their window.
4. Responses: status 429 with a Retry-After header.
5. Fail-open or fail-closed: decide what happens if the shared store is down; login endpoints usually fail closed.

Prefer the edge for coarse limits, such as per-IP floods, and keep business limits, such as per-plan quotas, in the application.

Cross-origin resource sharing lets browsers call your API from pages on other origins. The server decides which origins, methods and headers are allowed by sending response headers; browsers enforce the rules, while non-browser clients ignore them.

How it works:

1. For simple requests, the browser sends the request with an Origin header and checks the response's Access-Control-Allow-Origin.
2. For other requests, such as those with JSON bodies or custom headers, the browser first sends an OPTIONS preflight request, and the server answers with allowed methods, headers and a cache duration.

Correct configuration:

• Allowlist origins: compare the incoming Origin with a configured list and echo it back only when it matches; never reflect arbitrary origins.
• Credentials: if cookies are needed, send Access-Control-Allow-Credentials: true, which is not allowed with a wildcard origin.
• Vary header: add Vary: Origin when the response depends on it, so caches do not serve one origin's headers to another.
• Preflight caching: set Access-Control-Max-Age to reduce preflight requests.
• Answer preflights early, in middleware, without running authentication or business logic.

Remember: CORS is not an authorization mechanism; every request still needs authentication and authorization on the server.

Send data in chunks as it is produced instead of building the whole response in memory. This keeps memory flat for large exports and lets clients start receiving data immediately.

Techniques:

1. Disable or flush output buffering with ob_end_flush or flush, so chunks reach the web server instead of accumulating.
2. Write rows as you read them: fetch database rows one at a time and write each as a line of CSV or newline-delimited JSON.
3. Stream files with readfile or by copying a file stream to the output with stream_copy_to_stream, rather than loading files into strings.
4. Set headers first: content type, Content-Disposition for downloads and no Content-Length when the size is unknown.
5. Raise time limits only for these endpoints, and stop work when the client disconnects, checking connection_aborted.

Server considerations:

• Web servers and proxies may buffer responses; configure them to pass streamed responses through for these routes.
• Long-running exports tie up PHP workers, so for very large files, generate them in a background job and send a download link.
• For static files, let the web server serve them directly, using a signed or internal redirect, which is far cheaper than streaming through PHP.

HTTP headers must be sent before the body. As soon as PHP outputs any byte of the body, such as an echo, whitespace before the opening <?php tag or a warning message, it sends the headers, and later calls to header, setcookie or session_start fail with "headers already sent".

Common causes:

1. Whitespace or a byte order mark before <?php or after a closing ?> tag in an included file.
2. Debug output or warnings printed before redirects.
3. Starting the session after sending part of the page.

Fixes:

• Omit the closing ?> tag in files that contain only PHP code.
• Save files as UTF-8 without a byte order mark.
• Turn off display_errors in production and log warnings instead.
• Structure code so responses are built first and sent once: the handler returns a response object, and the front controller sends headers and body at the end.

Output buffering collects output in memory and sends it later, which hides the problem but does not fix it, and it wastes memory for large responses. Use it deliberately, for example to capture a template's output, rather than as a global workaround.

Caching headers tell clients and proxies how long a response may be reused. Conditional requests let a client ask "has this changed?" with a validator, such as an entity tag, and receive a short 304 Not Modified response instead of the full body when nothing changed.

Key headers:

• Cache-Control: max-age=60 allows reuse for a minute; private limits caching to the user's browser; no-store forbids storing sensitive responses.
• ETag: a validator, often a hash of the response body or a version number.
• If-None-Match: the client sends the entity tag it has; if it matches, the server returns 304.
• Last-Modified and If-Modified-Since: a time-based alternative.

Practical advice:

1. Compute entity tags cheaply, such as from a row version or update timestamp, without rendering the full response.
2. Mark personalized responses private, and never let shared caches store authenticated data.
3. Use entity tags with If-Match on updates, too, for optimistic concurrency.

Publish a machine-readable description of every endpoint, its parameters and responses, keep it in version control next to the code and version the API when you must make breaking changes.

Documentation practices:

1. Describe the contract in a standard machine-readable format, generated from code annotations or written by hand and checked in continuous integration.
2. Include examples of requests, responses and errors.
3. Generate client code or contract tests from the description, so documentation and behavior cannot drift apart.

Avoiding breaking changes: add fields rather than renaming them, make new inputs optional, keep old versions running during migration and announce deprecations with dates and usage metrics.

Read configuration from environment variables, or from files provided by the deployment platform, at startup, convert values to the right types, validate them and pass a configuration object to the rest of the code. The same build then runs in every environment with different settings.

Practices:

1. One configuration class that reads, converts and validates all settings, failing fast with a clear message when something is missing or invalid.
2. Typed values: convert strings to integers, Booleans and enums explicitly; getenv and $_ENV always return strings.
3. Secrets from secret stores or mounted files, never committed to the repository; local development can use an untracked environment file.
4. Cache configuration in production, for example in a generated PHP file that the bytecode cache keeps in memory, so it is not parsed on every request.
5. No configuration reads scattered through the code; pass the configuration object to services that need it.

Watch for: process managers that clear environment variables for workers by default, which requires explicitly passing or allowing them.

Write structured log records, usually JSON lines, to standard output or standard error in containers, or to files collected by an agent. Each record should include a level, a message, a timestamp, the request ID and relevant fields, so logs can be searched and correlated.

Good practices:

1. A logging interface injected into services, rather than calling error_log or echo throughout the code, so output format and destination can change in one place.
2. Levels used consistently: errors for failures needing attention, warnings for handled anomalies and information for key business events.
3. Context, not concatenation: pass fields such as order_id separately from the message.
4. A request ID generated at the entry point, or taken from the proxy, added to every record and returned in error responses.
5. Never log secrets or sensitive personal data: passwords, tokens, full card numbers or session IDs.
6. Log exceptions once, with the stack trace, at the boundary where they are handled.

PHP-specific settings: turn on log_errors, turn off display_errors in production and make sure warnings and notices are logged rather than printed into responses.

Separate the entry point, the HTTP layer, the business logic and the infrastructure, and organize the business logic by feature. Keep the public web directory minimal and everything else outside it.

flowchart TD
  A["public/index.php: front controller"] --> B["Http: routes, controllers, middleware"]
  B --> C["Orders: domain and use cases"]
  B --> D["Billing: domain and use cases"]
  C --> E["Infrastructure: database, queues, external clients"]
  D --> E
  F["config: wiring and settings"] --> A

Principles:

1. Public directory contains only the front controller and static assets.
2. Feature modules, such as orders and billing, each with entities, services and interfaces for what they need.
3. Thin controllers: parse the request, call a use case and build the response.
4. Infrastructure behind interfaces defined in the modules, so tests can use fakes and storage can change.
5. Configuration and wiring in one place, usually a container setup file.
6. Tests mirror the source structure.

Avoid: business logic in templates or controllers, global helper functions with hidden dependencies and generic folders such as utils that grow without structure.

Pass each class its dependencies through the constructor, typed as interfaces where useful, and create the object graph in one composition place, such as a small container or a factory file. Classes never construct their own collaborators or reach into global state.

Benefits:

• Dependencies are explicit in constructor signatures.
• Tests pass fakes instead of real databases or HTTP clients.
• Configuration and wiring live in one place.

Practices:

1. Constructor promotion keeps injection code short.
2. Interfaces for boundaries: repositories, clocks, mailers and payment gateways.
3. Inject configuration values as typed parameters or configuration objects.
4. Lazy creation for expensive services, through factories or closures that create the object on first use.
5. Avoid the service locator pattern, where classes fetch dependencies from a global container, since it hides dependencies.

When a container helps: with many services, a container that resolves constructor parameters automatically through reflection saves boilerplate; cache its resolution in production for speed.

Interview tip: describing how you would test a class that sends emails, by injecting a fake mailer interface, is a concise way to show you understand why injection matters.

PDO is PHP's common database interface. Configure it once to throw exceptions and return associative arrays, use prepared statements for every query with values and share one connection per request through dependency injection.

Recommended settings:

1. PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, so errors are never silently ignored.
2. PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, so rows are arrays keyed by column name only.
3. Native prepared statements where the driver supports them, by turning off emulation, so types travel correctly.
4. Character set in the connection string, so text is stored and read as UTF-8.

Usage habits:

• Prepare once, execute many times for repeated inserts.
• Bind integers with PDO::PARAM_INT where the type matters, such as LIMIT.
• Iterate statements directly with foreach, or fetch in chunks, instead of fetchAll on huge results.
• Handle constraint violations by catching PDOException and checking the SQLSTATE code, such as 23000 for integrity constraint violations.
• Read the connection string, user and password from configuration, never from source code.

Start a transaction with beginTransaction, run the related statements, call commit when all succeed and rollBack if anything fails. Inside a transaction, other sessions see either all of its changes or none of them.

A safe pattern:

1. Begin the transaction.
2. Run statements inside try.
3. Commit at the end of try.
4. In catch (Throwable $e), roll back and rethrow, so callers still see the failure.

Good practices:

• Wrap the pattern in a helper, such as transactional(callable $work), so every transaction is handled the same way.
• Let the database enforce rules with constraints, such as CHECK (balance >= 0), so invalid states fail inside the transaction.
• Keep transactions short: no HTTP calls, emails or slow computations inside them.
• Retry the whole transaction on deadlocks or serialization failures, and make it safe to repeat.
• Lock rows deliberately with SELECT ... FOR UPDATE where the database supports it, when you must read and then update the same row.

Nested transactions are not supported directly by PDO; use savepoints or a helper that tracks nesting depth.

An N+1 problem happens when code loads a list with one query, then runs another query for each item, such as loading each order's customer separately. With 50 items, that is 51 round trips to the database, and the cost grows with the list.

How to spot it:

1. Log or count queries per request in development, and look for repeated queries that differ only by an ID.
2. Watch for database calls inside loops, including hidden ones in lazy-loading model properties.

Fixes:

• Join the related table in the original query when you need a few columns.
• Batch load: collect the IDs, load all related rows with one IN query and index them by ID in an array.
• Eager loading in mappers that support it, which does the batching for you.
• Aggregate in SQL with GROUP BY instead of counting in PHP loops.

Watch the opposite problem: joins that multiply rows, such as orders joined to both items and payments, can produce huge result sets; two batched queries are sometimes better than one wide join.

Offset pagination, with LIMIT and OFFSET, is simple but gets slower on deep pages because the database must skip every earlier row. Keyset pagination remembers the last row's sort key and asks for rows after it, which stays fast at any depth.

Implementing keyset pagination well:

1. Sort by a unique, indexed key, or a pair such as (created_at, id) to break ties.
2. Return an opaque cursor, such as the encoded last key, rather than raw values, so the format can change.
3. Fetch one extra row to know whether another page exists.
4. Validate the page size against a maximum.

Total counts are expensive on large tables; show approximate counts or omit them.

Keep schema changes as versioned migration files in the repository, apply them automatically in order during deployment and record which ones have run in a table in the database. Every environment then has the same schema history.

Practices:

1. One change per migration, with a timestamp or sequence number in the file name.
2. Never edit a migration that has run in a shared environment; add a new one instead.
3. Run migrations in the deployment pipeline, before or as part of releasing the new code, with a lock so two deployments cannot run them at once.
4. Test migrations against a copy of production-sized data, since some changes lock tables for a long time.

Zero-downtime changes, for applications that keep serving during deployment:

• Expand, then contract: add new columns or tables first, deploy code that writes to both old and new structures, backfill, switch reads and remove old structures in a later release.
• Make new columns nullable or give them defaults, so old code can still insert rows.
• Create indexes without blocking writes, using the database's online index options.
• Backfill in batches to avoid long locks and replication lag.

Rollbacks of schema changes are risky; prefer forward fixes, and keep destructive steps for a later, separate release.

In the request-per-process model, each request normally opens a database connection when first needed and closes it at the end of the request. Opening connections is not free, especially with TLS, so high-traffic applications reduce that cost in one of three ways.

Options:

1. Persistent connections: PDO's persistent option keeps the connection open in the worker process and reuses it for the next request. It saves connection time, but every worker holds a connection, and state left by one request, such as open transactions or session settings, can leak into the next.
2. An external connection pooler between PHP and the database, which multiplexes many short client connections onto fewer database connections.
3. Long-running application servers, which keep a connection pool in memory across requests.

Sizing: the total number of database connections equals the number of PHP workers across all servers, plus background workers. A pool of 200 workers on five servers can mean 1,000 connections, which many databases cannot handle well.

Good practices:

• Size worker pools with the database's connection limit in mind.
• Reset or close connections cleanly after errors.
• Monitor connection counts and wait times on the database side.

PHP applications cache at several levels: compiled code, application data within one request, data shared across requests and whole HTTP responses. Each level removes a different kind of repeated work.

Data caching practices:

1. Cache-aside: read from the cache; on a miss, load from the source, store with an expiry and return.
2. Keys include every input that affects the value, such as tenant, language and version.
3. Expiry and invalidation: short lifetimes for changing data, and explicit deletion when the source changes.
4. Stampede protection: when a popular entry expires, let one request rebuild it, using a short lock, while others serve the old value.
5. Per-request memoization in a simple array for values used many times within one request.

Measure hit rates, and remember that cached data can be stale; never cache permissions or prices longer than the business accepts.

Move slow or unreliable work, such as sending emails, generating reports or calling partner APIs, out of the request into a queue. Long-running PHP worker processes take jobs from the queue, process them and acknowledge them, while the web request returns immediately.

flowchart LR
  A["Web request"] --> B["Validate and save data"]
  B --> C["Push job to queue"]
  C --> D["Return response quickly"]
  E["Queue"] --> F["Worker processes"]
  C --> E
  F --> G{"Job succeeded?"}
  G -->|Yes| H["Acknowledge"]
  G -->|No| I["Retry with backoff, then dead-letter"]

Worker design:

1. Idempotent jobs: a job may run twice after a crash or timeout, so check state before acting.
2. Small payloads: store IDs in the job, and load fresh data when processing.
3. Restart workers regularly, after a number of jobs or on memory growth, since state and leaks accumulate in long-running PHP processes.
4. Graceful shutdown: handle termination signals, finish the current job and stop taking new ones.
5. Supervision: a process supervisor or orchestrator keeps the right number of workers running.
6. Monitoring: queue length, oldest job age, failures and dead-letter size.

Push jobs only after the database transaction commits, or use an outbox table, so workers never see jobs for data that was rolled back.

In the classic model, each request starts the application from scratch and throws everything away at the end. Long-running application servers keep the application booted in memory and handle many requests in the same process, which removes bootstrap cost but changes the rules developers must follow.

Rules for long-running servers:

1. No request data in static properties or singletons; reset services that hold per-request state between requests.
2. Close or reset connections that may be left in a bad state.
3. Restart workers periodically as a safety net.
4. Avoid blocking calls where the server uses asynchronous input and output, since one blocking call stalls other requests.
5. Test for state leaks by sending sequences of requests from different users.

Test small units of behavior through their public methods with fast, isolated tests. PHP's common test frameworks share the same model: test classes with test methods, assertions, data providers for many input cases and setup methods that build the object under test.

Structure each test as arrange, act and assert:

1. Arrange: build the object with fake dependencies and inputs.
2. Act: call one method.
3. Assert: check the returned value, the state change or the message sent.

Good practices:

• Name tests by behavior, such as "refund is rejected after 30 days".
• Data providers for many cases of one rule, including edge cases.
• Inject the clock, random values and identifiers, so tests are deterministic.
• No real network or database in unit tests; use fakes behind interfaces.
• Test failure paths, such as exceptions and validation errors.
• Keep tests fast, so developers run them constantly.

Beyond unit tests: integration tests against a real database engine, HTTP-level tests of the front controller and a small number of end-to-end tests.

Measure usefulness, not just coverage: mutation testing tools change the code slightly and check that tests fail, revealing assertions that are too weak.