Laravel 5-Year Interview (Q1–25)

Solution and explanation

// One-to-one: $user->profile
public function profile() { return $this->hasOne(Profile::class); }

// One-to-many: $user->orders
public function orders() { return $this->hasMany(Order::class); }

// Many-to-many: $user->roles
public function roles() { return $this->belongsToMany(Role::class); }

// Belongs-to: $order->user
public function user() { return $this->belongsTo(User::class); }

• Laravel also supports hasManyThrough, hasOneThrough and polymorphic relationships (morphTo, morphMany, morphToMany).

Solution and explanation

$orders = Order::all();

foreach ($orders as $order) {
    echo $order->user->name;   // one extra query per order
}

• This creates the N+1 query problem.
• Eager load instead:

$orders = Order::with('user')->get();

Without eager loading: 1 query for orders + 100 queries for users = 101 queries
With eager loading:    1 query for orders + 1 query for users    = 2 queries

• This is extremely important in production Laravel applications.

Solution and explanation

• Lazy loading means a relationship is queried only when it is first accessed.

$order = Order::find(1);

echo $order->user->name;   // the user query runs here

• Advantage: simple and convenient for a single record.
• Disadvantage: inside loops it silently produces N+1 queries.
• For lists, prefer Order::with('user')->get(), and enable Model::preventLazyLoading() in development to catch mistakes.

Solution and explanation

• Suppose there are 1,000 products:

$products = Product::all();

foreach ($products as $product) {
    echo $product->category->name;
}

1 product query + 1,000 category queries = 1,001 queries

• Solution:

$products = Product::with('category')->get();   // about 2 queries

• How to identify it: Laravel Debugbar, query logging, Telescope, application performance monitoring, database monitoring, and Model::preventLazyLoading() during development.

Solution and explanation

• A very common 5-year scenario.
• Don't immediately say "use Redis"; first identify the bottleneck.

• Step 1, database: check slow queries, missing indexes, N+1 queries, large SELECT *, unnecessary joins and poor pagination.

// Only one row is needed:
User::where('email', $email)->first();

// Add an index:
$table->index('email');

• Step 2, Eloquent: eager load and select only required columns.

Order::with(['user', 'items.product'])->get();

User::select(['id', 'name', 'email'])->get();

• Step 3, cache frequently requested data (Redis in distributed, high-traffic setups).

$products = Cache::remember('products', 3600, fn () => Product::latest()->get());

• Step 4, queues: don't do slow work during the HTTP request.

User places order → save order → return response
                                   ↓ queue: email, invoice, SMS, notifications

SendOrderConfirmation::dispatch($order);

• Step 5, pagination and chunking instead of Product::all() on millions of rows.

Product::paginate(50);

Product::chunkById(1000, function ($products) {
    //
});

• Step 6, HTTP and API: pagination, caching, compression, CDN, HTTP caching and lean JSON responses.

• Step 7, infrastructure for high traffic:

Load Balancer
      ↓
Laravel Server 1 / Server 2 / Server 3
      ↓
Redis
      ↓
Database (with read replicas where appropriate)

• Use PHP OPcache, Redis, queue workers under Supervisor or systemd, Horizon where applicable, database indexes, a CDN and horizontal scaling.

• Strong 5-year answer: "I don't optimize Laravel blindly.
• First I identify whether the bottleneck is CPU, database, memory, network or external services.
• For database issues I inspect slow queries, indexes and N+1 problems.
• For repeated reads I add caching, usually Redis in a distributed environment.
• For expensive work I use queues.
• I also optimize pagination, eager loading, selected columns and API payloads, and at infrastructure level I use OPcache, multiple application instances behind a load balancer and appropriate database scaling."