System-design and implementation scenarios

Status: Complete. Last reviewed 2026-08-28.

These are specification exercises, not canonical interview questions or tutorial builds. Each heading is a stable exercise anchor; the scenario supplies a contract of required behavior, failure conditions, evidence, and owning guidance. Clarify assumptions, record decisions and trade-offs, implement only the smallest credible slice when code is useful, and verify the stated evidence. Polished UI is optional, and canonical prompts and answers remain in the linked topical banks.

1. Idempotent webhook receiver

Build a Laravel endpoint that authenticates a signed webhook, rejects stale/replayed requests, durably records receipt, returns quickly, processes asynchronously, deduplicates delivery and exposes operational status.

Evidence: threat model, schema constraints, retry tests, failure metrics and an explanation of acknowledged-but-not-processed state.

Owning guidance: HTTP and API design and distributed delivery and reliability.

2. Concurrent booking

Reserve a limited resource without double booking. Implement two strategies—row locking and optimistic/constraint-based control—and compare contention, failure UX and testability.

Evidence: concurrency test, query plan and invariant definition.

Owning guidance: databases, indexes, and concurrency and the booking decision sketch.

3. Resumable import

Process a large file with bounded memory, per-row validation, progress, cancellation, retry and partial-failure reporting. Avoid one job per row unless measurements justify it.

Evidence: memory profile, queue design, idempotency policy and deployment behavior.

Owning guidance: concurrency, processes, and asynchronous I/O and the import decision sketch.

4. Modular monolith boundary

Extract a cohesive domain from a conventional Laravel application without creating a framework-avoidance layer. Define public operations/events, dependency direction and transaction ownership.

Evidence: ADR explaining what remained coupled to Laravel and why.

Owning guidance: architecture and domain-driven design, software design, and technical leadership.

5. AI-assisted review workflow

Design a tool-assisted reviewer for Laravel changes. Bound it to advisory findings on pull requests, define repository and data access, and decide when it must abstain or require human approval. Include direct and indirect prompt injection, malicious dependencies, excessive agency, provider failure, and model or prompt changes in the threat and operational model.

Implement the smallest credible workflow and distinguish immediate containment from root fixes when an injected repository file attempts a tool call. Verify narrow tool schemas, authorization outside the model, bounded/redacted results, an auditable decision trail, and a disable path. Evaluate held-out Laravel cases against unaided review and the existing review process; report precision/recall by severity, harmful suggestions, review time, latency, cost, and important slices rather than one score.

Evidence: task and trust-boundary record, representative eval set and rubric, false-positive/negative analysis, adversarial end-to-end trace, approval evidence, tool audit events, and a model/prompt/tool change gate. Discussion should separate prompting, retrieval, fine-tuning, and tools; protocol from capability; and generated claims from verified evidence.

Owning guidance: AI-assisted development, the tool-boundary example, testing and quality, and application and operational security. Use the linked canonical practice on the AI guidance page rather than duplicating its prompts here.

6. Multi-tenant SaaS control plane

Design and implement a tenant-aware project and export service. Every HTTP request, queued export, cache entry, object-storage path and administrative action must preserve tenant scope. Support one very large tenant, per-tenant quotas, a tenant move between placement groups, data residency, and restoration of one tenant without exposing or overwriting another.

Compare shared-table, schema-per-tenant and database/placement-group models against the stated isolation, operational and cost constraints. Choose one initial model and define measured triggers for changing it. Include tenant-local unique constraints, authorization after job delay, connection/context reset in long-lived workers, signed download capability, audit events and a break-glass support path.

Inject attempts to substitute tenant IDs, reuse cache keys, replay an export job under a different context, exhaust shared workers, and run a migration while old and new application versions coexist.

Evidence: threat model and trust boundaries, schema and routing design, isolation tests across every storage/async boundary, noisy-neighbor load results, migration/restore rehearsal, safe telemetry examples and an ADR with reversal triggers.

Owning guidance: system-design tenancy sketch, application and operational security, database guarantees and performance/capacity.

7. Multi-channel notification platform

Design and implement a service that accepts notification intents and delivers email, SMS and push according to user preferences, urgency and provider policy. Distinguish accepted, scheduled, provider-accepted, delivered where evidence exists, failed, suppressed and cancelled states. Support bulk fan-out, quiet hours and time zones, template versions, per-tenant/provider quotas, provider failover and user-visible status without claiming that “sent” proves delivery.

Define stable intent, recipient and channel-attempt identities. Make duplicate API requests, message redelivery and worker crashes repeat-safe; preserve preference and template semantics chosen for a scheduled notification; and specify ordering only where the product requires it. Bound fan-out and retries so one campaign or provider outage cannot starve urgent traffic. Reconcile ambiguous provider outcomes and decide when fallback to another channel is acceptable rather than duplicative or harmful.

Inject provider throttling, timeout after provider acceptance, duplicate and out-of-order delivery events, preference change during fan-out, poison templates, deploy/restart and exhausted dead-letter handling.

Evidence: API/state-machine and message schemas, idempotency constraints, capacity model, retry/fallback matrix, preference and authorization tests, failure-injection traces, reconciliation report, SLOs and an operator redrive procedure.

Owning guidance: system-design notification sketch, distributed delivery and reliability, concurrency and backpressure and HTTP and API design.