Advanced Level Development Software Architecture

Laravel Microservices: Advanced Architectural Patterns

November 17, 2024 / November 17, 2024 by Yogi Nugraha | Leave a comment

Hey there, fellow Laravel enthusiasts! 👋 Ready to dive deep into the world of microservices? We’re gonna break down some seriously cool patterns and show you how to level up your Laravel game. Let’s get this party started! 🚀

Introduction
Foundational Concepts
Core Architectural Patterns
Implementation Guidelines
Advanced Patterns
Monitoring and Observability
Real-World Example
Common Pitfalls
Tools and Technologies
Conclusion

Introduction

So you’ve got this massive Laravel monolith that’s becoming a pain to maintain? Been there, done that! Let’s talk about breaking it down into microservices – but we’re not just gonna cover the basics. We’re diving into the advanced stuff that makes microservices really shine in Laravel.

Why Laravel for microservices? Well, with its powerful service container, event broadcasting, and job queuing capabilities, Laravel’s practically begging to be used for microservices. Plus, it’s got some sweet features that make building distributed systems a breeze.

Foundational Concepts

Before we jump into the fancy stuff, let’s get our heads straight about what we’re dealing with:

Microservices vs Monolithic: The Real Deal

// Monolithic Approach 😓
class OrderController extends Controller
{
    public function process(Request $request)
    {
        // Everything happens here - validation, payment, inventory, shipping
        $order = Order::create($request->all());
        $payment = Payment::process($order);
        $inventory->update();
        $shipping->schedule();
        // It's a mess!
    }
}

// Microservices Approach 😎
class OrderController extends Controller
{
    public function process(Request $request)
    {
        // Create order and let other services handle their business
        $order = Order::create($request->all());

        // Fire and forget - other services will pick this up
        event(new OrderCreated($order));

        return response()->json([
            'message' => 'Order is being processed',
            'order_id' => $order->id
        ]);
    }
}

Key Principles (The TL;DR Version)

Loose Coupling: Services should be like that one friend who’s cool doing their own thing
High Cohesion: Keep related stuff together, like pineapple on pizza (controversial, I know 🍕)
Bounded Contexts: Draw clear lines around your services – no sneaking across borders!

Core Architectural Patterns

Service Discovery: Finding Your Friends

Here’s a neat way to implement service discovery using Redis:

class ServiceRegistry
{
    private $redis;

    public function __construct()
    {
        $this->redis = Redis::connection();
    }

    public function register(string $serviceName, string $url): void
    {
        $this->redis->hset('services', $serviceName, json_encode([
            'url' => $url,
            'last_heartbeat' => now()->timestamp,
            'status' => 'healthy'
        ]));
    }

    public function discover(string $serviceName): ?string
    {
        $service = $this->redis->hget('services', $serviceName);
        return $service ? json_decode($service)->url : null;
    }
}

Circuit Breaker: Because Everyone Needs a Break

Check out this slick circuit breaker implementation:

class CircuitBreaker
{
    private $redis;
    private $threshold = 5;
    private $timeWindow = 60;

    public function execute(callable $action, string $service)
    {
        if ($this->isOpen($service)) {
            throw new ServiceUnavailableException("Circuit is open for {$service}");
        }

        try {
            $result = $action();
            $this->recordSuccess($service);
            return $result;
        } catch (Exception $e) {
            $this->recordFailure($service);
            throw $e;
        }
    }

    private function isOpen(string $service): bool
    {
        $failures = $this->redis->get("circuit:{$service}:failures") ?? 0;
        return $failures >= $this->threshold;
    }
}

Implementation Guidelines

Service Communication: Pick Your Poison

REST APIs with Laravel Sanctum

Route::middleware('auth:sanctum')->prefix('api/v1')->group(function () {
    Route::post('/orders', [OrderController::class, 'store']);
    Route::get('/orders/{order}', [OrderController::class, 'show']);
});

Message Queues with Redis

// In your service provider
Event::listen(OrderCreated::class, function ($event) {
    Redis::publish('orders.created', json_encode([
        'order_id' => $event->order->id,
        'total' => $event->order->total,
        'customer' => $event->order->customer_id
    ]));
});

Data Consistency: The Truth is Out There

Here’s a cool event sourcing pattern to maintain data consistency:

abstract class AggregateRoot
{
    private array $pendingEvents = [];

    protected function recordEvent(DomainEvent $event): void
    {
        $this->pendingEvents[] = $event;
    }

    public function releasePendingEvents(): array
    {
        $events = $this->pendingEvents;
        $this->pendingEvents = [];
        return $events;
    }
}

class Order extends AggregateRoot
{
    public function place(): void
    {
        // Business logic...
        $this->recordEvent(new OrderPlaced($this));
    }
}

Advanced Patterns

Saga Pattern: For When Things Get Complex

Here’s a tasty implementation of the Saga pattern:

class OrderSaga
{
    public function process(Order $order)
    {
        try {
            // Start the saga
            DB::beginTransaction();

            // Step 1: Reserve inventory
            $inventory = $this->inventoryService->reserve($order->items);

            // Step 2: Process payment
            $payment = $this->paymentService->charge($order->total);

            // Step 3: Create shipping label
            $shipping = $this->shippingService->createLabel($order);

            DB::commit();

        } catch (Exception $e) {
            // Something went wrong - roll it back!
            DB::rollBack();
            $this->compensate($order, $e);
            throw $e;
        }
    }

    private function compensate(Order $order, Exception $e)
    {
        // Clean up the mess
        if (isset($inventory)) {
            $this->inventoryService->release($order->items);
        }
        if (isset($payment)) {
            $this->paymentService->refund($payment);
        }
        // Log what happened
        Log::error('Saga failed', [
            'order' => $order->id,
            'error' => $e->getMessage()
        ]);
    }
}

Real-World Example: E-commerce System

Let’s build a sweet e-commerce system! Here’s how we’ll break it down:

Services Architecture

┌─────────────────┐     ┌─────────────────┐
│   API Gateway   │─────▶ Auth Service    │
└────────┬────────┘     └─────────────────┘
         │
         ├────────────▶ ┌─────────────────┐
         │              │ Product Service  │
         │              └─────────────────┘
         │
         ├────────────▶ ┌─────────────────┐
         │              │  Order Service   │
         │              └─────────────────┘
         │
         └────────────▶ ┌─────────────────┐
                        │ Payment Service  │
                        └─────────────────┘

Docker Configuration

version: '3.8'

services:
  api-gateway:
    build: 
      context: ./api-gateway
      dockerfile: Dockerfile
    ports:
      - "8000:80"
    networks:
      - microservices-net

  auth-service:
    build:
      context: ./auth-service
      dockerfile: Dockerfile
    environment:
      - DB_CONNECTION=mysql
      - DB_HOST=auth-db
    networks:
      - microservices-net

networks:
  microservices-net:
    driver: bridge

Common Pitfalls

Listen up, here are some gotchas to watch out for:

Service Boundaries Too Small
- Don’t go crazy creating services for everything
- Rule of thumb: If it changes together, it belongs together

Distributed Monolith

// DON'T DO THIS 🚫
class OrderService
{
    public function process(Order $order)
    {
        // Directly calling other services... yuck!
        $productService->checkStock();
        $userService->validateUser();
        $paymentService->processPayment();
    }
}

// DO THIS INSTEAD ✅
class OrderService
{
    public function process(Order $order)
    {
        // Create the order
        $order = Order::create($data);

        // Let other services know what's up
        event(new OrderCreated($order));

        // Return immediately
        return $order;
    }
}

Tools and Technologies

Here are some must-have tools for your Laravel microservices journey:

Monitoring Setup with Prometheus

// In your ServiceProvider
public function boot()
{
    $this->app->singleton(PrometheusMetrics::class, function () {
        return new PrometheusMetrics([
            'namespace' => 'order_service',
            'metrics' => [
                'orders_processed_total' => [
                    'type' => 'counter',
                    'help' => 'Total orders processed'
                ],
                'order_processing_duration' => [
                    'type' => 'histogram',
                    'help' => 'Time taken to process orders'
                ]
            ]
        ]);
    });
}

Conclusion

Alright, we’ve covered a lot of ground! Here’s your TL;DR for when to use these patterns:

Use Circuit Breakers when you need to handle service failures gracefully
Go for Saga Pattern when you’ve got complex transactions across services
Implement Event Sourcing when you need a reliable audit trail

Remember, microservices aren’t a silver bullet – they’re just another tool in your toolbox. Use them wisely, and they’ll make your life easier. Use them wrongly, and well… let’s just say you’ll have some interesting stories for your next tech meetup! 😅

What’s Next?

Check out service mesh technologies like Istio
Look into GraphQL for flexible API queries
Keep an eye on WebAssembly – it might change the game!

Happy coding! And remember, with great power comes great responsibility… and a lot of Docker containers! 🐳

Got questions? Found a bug? Want to share your war stories? Hit me up in the comments below! 👇

Table of Contents