How would you architect a high-throughput PHP 8 service?

Long Answer

Designing a modern PHP 8 service architecture for high throughput means removing avoidable work from the hot path, drawing crisp domain seams, and treating asynchronous execution and shutdown as first-class concerns. Laravel and Symfony provide excellent foundations; the key is how you shape modules, handle concurrency, and operate the runtime.

1) Domain boundaries and layering
Organize by bounded contexts (Accounts, Catalog, Checkout, Billing). Each context contains Domain (entities, value objects, policies), Application (use cases, orchestrators), and Infrastructure (ORM repositories, HTTP clients, queue producers). Framework code remains at the edge: controllers adapt transport to use cases; they never contain business logic. Contracts are explicit via DTOs and events so modules evolve independently.

2) HTTP workers to eliminate cold starts
Traditional FPM reboots the framework every request. RoadRunner or Swoole keeps the application warm inside a long-lived worker, removing autoload and container setup from the hot path. Use a single container build per worker, but avoid global mutable state. For Laravel, use Octane with RoadRunner or Swoole. For Symfony, boot the kernel once and reset per request using request scope and middleware that clears per-request services. Ensure all services are stateless or resettable between requests (no cached user context, no leaked connections).

3) Async pipelines and queues
Push slow or bursty work to queues (SQS, RabbitMQ, Redis Streams). Adopt the outbox pattern: write domain data and an outbox record in one transaction; a publisher relays events to the broker. Consumers are idempotent and time-bounded with visibility timeouts, dead-letter queues, and exponential backoff with jitter. Partition queues by domain and sometimes by tenant to avoid noisy neighbors. Use a job key for de-duplication and exactly-once effects at the application level.

4) Data access and caching
Encapsulate persistence behind repositories or query objects. Use read models and caching for hot paths: per-resource cache keys, short TTLs, and tag-based invalidation on events. Pool database connections and configure circuit breakers and timeouts for external calls. Prefer prepared statements and avoid N+1 queries with eager loading. For full-page responses, layer HTTP cache and ETags with safe invalidation.

5) Per-route budgets and backpressure
Apply concurrency and time budgets per endpoint. Lightweight endpoints have higher concurrency; heavy endpoints have strict limits. Enforce budgets with middleware: rate limiters, request timeouts, and bulkheads to keep health checks and authentication responsive. When saturated, return clear 429 or 503 responses with retry hints rather than letting requests pile up.

6) Observability and performance
Instrument structured logs with correlation identifiers and tenant identifiers if multi-tenant. Track RED metrics (rate, errors, duration), queue depth, worker utilization, and percentiles. Expose runtime health (ready versus live) and feature flags. Use profiling to detect hot allocations and container misconfigurations. Treat tail latency as a release gate.

7) Safe graceful shutdowns end to end
Shutdown begins at the edge: set the instance to not-ready, stop accepting new requests, and drain in-flight ones with a deadline. For long-running jobs, support checkpointing and idempotent resume. Workers receive signals (TERM, QUIT) and complete current tasks or save progress before exit. For RoadRunner or Swoole, hook into onWorkerStop to close pools and flush telemetry. For consumers, extend visibility timeouts while finishing, and nack to requeue when the deadline is exceeded. Roll deploys in small batches to keep capacity stable.

8) Testing and evolution
Adopt a pyramid: unit tests for domain rules, integration tests for repositories and messaging, and a small set of end-to-end flows. Contract tests protect public APIs and event schemas. Database and event migrations follow expand → migrate → contract with backfills running in workers. Keep rollbacks ready and observability dashboards pinned during releases.

This combination of domain discipline, warm workers, async queues, and deliberate graceful shutdowns yields a predictable, fast PHP 8 service architecture that scales without losing correctness.

‍

Table

‍

Common Mistakes

• Treating Laravel or Symfony as the domain and placing business logic in controllers or models.
  
• Running only under FPM and accepting per-request boot penalties despite high traffic.
  
• Skipping the outbox and writing to the database and broker separately, causing drift or duplicates.
  
• Global queues where one heavy tenant or job type starves others; no DLQ or backoff.
  
• Stateful singletons in warm workers that leak per-request data across users.
  
• No per-route budgets, letting expensive endpoints starve health and authentication.
  
• Unbounded retries that hammer dependencies during incidents; no circuit breakers.
  
• Abrupt restarts without readiness gates and draining, losing in-flight requests or jobs.
  
  

Sample Answers (Junior / Mid / Senior)

Junior:
“I would keep controllers thin and move logic to services and repositories. I would push heavy work to a queue like SQS and make jobs idempotent. I would cache hot reads and add timeouts for external calls. For deploys, I would drain requests before stopping workers.”

Mid:
“My PHP 8 service architecture uses bounded contexts and runs on RoadRunner with Laravel Octane to avoid per-request boot. Writes use an outbox that a publisher sends to RabbitMQ. Consumers are partitioned per domain with DLQs and jittered retries. I apply per-route concurrency limits and timeouts, pool database connections, and expose RED metrics and queue depth. Deploys mark instances not-ready, drain, and shut down gracefully.”

Senior:
“I split the platform into domains with explicit contracts, run warm HTTP workers (RoadRunner or Swoole) with strict request resets, and treat async as default via outbox-backed events and idempotent consumers. Budgets and bulkheads protect latency. Observability covers P95, worker utilization, and backlogs. Graceful shutdowns coordinate readiness, draining, visibility extensions, and checkpointable jobs. Migrations follow expand → migrate → contract with backfills in workers.”

‍

Evaluation Criteria

A strong response defines a modern PHP service architecture with clear domain boundaries, thin controllers, repositories, and events. It should choose RoadRunner or Swoole to keep the app warm and describe how to reset per request to prevent state leaks. It must design async queues with an outbox, idempotent consumers, DLQs, and jittered backoff. It should enforce per-route budgets with concurrency limits, timeouts, and bulkheads, and apply caching and connection pooling. It should cover observability (RED metrics, queue depth, worker utilization) and detail graceful shutdowns for web workers and consumers. Red flags include controller-heavy logic, FPM only at scale, dual writes without outbox, global unpartitioned queues, and restarts without draining.

‍

Preparation Tips

• Create two domains (Orders, Billing) with Application services, repositories, and events.
  
• Run Laravel Octane on RoadRunner or boot Symfony kernel once; implement request reset middleware.
  
• Add an outbox table and a publisher worker; publish OrderPlaced to SQS or RabbitMQ.
  
• Implement consumers with idempotency keys, DLQs, and exponential backoff with jitter.
  
• Add per-route concurrency limits and timeouts; verify that health and authentication remain fast under load.
  
• Configure connection pools and cache read models with tag-based invalidation on events.
  
• Expose RED metrics, queue depth, worker utilization, and correlation identifiers; build a dashboard.
  
• Script a graceful shutdown: set not-ready, drain for N seconds, extend visibility for running jobs, checkpoint or nack on deadline, close pools, and exit.
  
• Practice expand → migrate → contract on an order schema with a backfill in workers.
  
  

Real-world Context

A retailer moved from FPM to RoadRunner with Laravel Octane and reduced median latency significantly by eliminating framework boot per request. Introducing an outbox stopped occasional duplicate orders during retries and enabled reliable event-driven features. Partitioned RabbitMQ queues with DLQs prevented a single importer from blocking fulfillment. Per-route budgets kept health checks and authentication responsive during launches. A disciplined graceful shutdown procedure prevented lost jobs and allowed zero-downtime deploys. With structured logs, queue depth, and worker utilization on dashboards, the team detected saturation early and scaled before user impact. The PHP 8 service architecture achieved high throughput without sacrificing correctness.

‍

Key Takeaways

• Draw domain boundaries and keep controllers thin; place logic in application services and repositories.
  
• Use RoadRunner or Swoole to run warm workers and reset state per request.
  
• Default to async with an outbox, idempotent consumers, DLQs, and jittered retries.
  
• Enforce per-route budgets and apply caching, pooling, and circuit breakers.
  
• Implement end-to-end graceful shutdowns with readiness gates, draining, and checkpointable jobs.
  
  

Practice Exercise

Scenario:
You are building a checkout and invoicing platform on PHP 8 (Laravel or Symfony). Spikes occur during flash sales. The system must keep tail latency low, process asynchronous payments reliably, and support zero-loss rolling deploys.

Tasks:

1. Define two bounded contexts (Checkout, Billing) with Domain, Application, and Infrastructure layers. Specify public commands, queries, and events.
   
2. Choose RoadRunner or Swoole. Describe how you will reset per-request state (container scoped bindings, clearing context, closing per-request resources) and prevent leaks.
   
3. Implement an outbox in the write database. Show the transaction that persists the order and outbox row, and the publisher that relays to SQS or RabbitMQ.
   
4. Design consumers for PaymentAuthorized and InvoiceIssued with idempotency keys, retries with jitter, DLQs, and per-queue concurrency.
   
5. Add per-route budgets: concurrency and timeouts for /checkout, /orders/{id}, and /health. Demonstrate that /health remains responsive during load.
   
6. Configure connection pools for database and HTTP clients. Add cache for order summaries with tag invalidation on OrderUpdated.
   
7. Instrument RED metrics, queue depth, worker utilization, and correlation identifiers; provide alert thresholds.
   
8. Write a graceful shutdown plan for both HTTP workers and consumers: set not-ready, drain, extend visibility timeouts, checkpoint long jobs, nack on deadline, flush telemetry, close pools, and exit.
   
9. Execute an expand → migrate → contract change adding tax_amount to orders; backfill via consumer and flip reads when complete.
   
   

Deliverable:
A concise architecture and runbook that demonstrate a high-throughput modern PHP service architecture with queues, warm HTTP workers, and reliable graceful shutdowns.