Real-time Chat Application

Messenger - Real-time Chat Application

Realtime messaging · Modular Laravel backend · Self-managed event pipeline

Role: Solo developer. I designed the architecture, built the product, and deployed the full stack myself.

Laravel · Next.js · TypeScript · Redis · Socket.io · Docker · MySQL · Redux Toolkit · React Query

Messenger is a chat product for direct messages and groups. It supports media sharing, reactions, seen state, and live sidebar updates without polling. The main technical goal was making the full realtime path visible and controllable, from database write to Redis pub/sub to Socket.io delivery on the client.

System Architecture

graph LR
    Client["Next.js Client"]
    Nginx["Nginx<br/>Reverse Proxy"]
    PHP["PHP-FPM<br/>Laravel API"]
    MySQL["MySQL 8"]
    Redis["Redis"]
    Echo["Laravel Echo Server"]
    Worker["Queue Worker<br/>Supervisor"]

    Client -->|HTTP API| Nginx
    Nginx --> PHP
    PHP --> MySQL
    PHP -->|Broadcast event| Redis
    Redis -->|Pub/Sub| Echo
    Echo -->|Socket.io| Client
    PHP -->|Queue job| Redis
    Redis -->|Process job| Worker
    Worker --> MySQL

The product uses a self-hosted Echo Server rather than a managed push service. That trade-off increases operational responsibility, but it made the event pipeline transparent and tunable.

Real-time Messaging

Problem: Chat UX falls apart if a message, status update, or sidebar preview waits on polling. But trusting every inbound real-time event blindly can also create duplicates or stale state after reconnects.

Solution: Build an event-driven delivery path backed by Redis pub/sub and a client strategy that combines socket events with controlled refetches after reconnect.

Implementation highlights:

• The API stores the message then broadcasts MessagesSentEvent
• Redis carries the event to Laravel Echo Server
• Socket.io pushes the event to subscribed clients
• The frontend updates Redux state immediately for message lists and sidebar previews
• Reconnect handling uses debounce and refetch instead of assuming every event is complete

Result: Conversations feel instant while state remains recoverable after transient connection problems.

sequenceDiagram
    participant A as User A (Browser)
    participant API as Laravel API
    participant R as Redis
    participant E as Echo Server
    participant B as User B (Browser)

    A->>API: POST /messages
    API->>API: Persist DB record + dispatch event
    API-->>A: 200 OK
    API->>R: Broadcast MessagesSentEvent
    R->>E: Pub/Sub channel
    E->>B: Socket.io emit
    B->>B: Update Redux store
    Note over B: Message list and sidebar update instantly

Modular Monolith

Problem: Chat, auth, media, and user management quickly become hard to maintain when all logic lives in a flat application structure.

Solution: Organize Laravel as a modular monolith with domain boundaries that mirror the real product.

Implementation highlights:

• Four main modules: Auth, Conversation, Media, and User
• Each module owns controllers, services, repositories, transformers, migrations, and routes
• Service classes call repositories instead of working directly against models
• The frontend mirrors the same separation with features/auth and features/chat

Result: Work on messaging no longer spills into unrelated auth or media code, and the domain boundaries remain understandable as the codebase grows.

graph TB
    subgraph Backend["Laravel Backend"]
        Auth["Auth Module<br/>Login, Register, OAuth"]
        Conv["Conversation Module<br/>Messages, Groups, Status"]
        Media["Media Module<br/>Upload, Storage, Transform"]
        User["User Module<br/>Profile, Contacts"]
    end

    subgraph Frontend["Next.js Frontend"]
        FAuth["features/auth<br/>Login, Register pages"]
        FChat["features/chat<br/>Chat UI, hooks, slices"]
    end

    Conv --> Media
    Conv --> User
    Auth --> User
    FChat --> FAuth

Dockerized Deployment

The runtime consists of seven cooperating services: PHP, Nginx, MySQL, Redis, Echo Server, queue workers, and Mailcatcher in development.

Key deployment choices:

• Docker Compose for both development and production variants
• Health checks so services only start once dependencies are ready
• Internal database/network isolation so MySQL and Redis are not publicly exposed
• Supervisor to keep queue workers alive after crashes

That deployment setup reduced machine setup time from manual hours to one command.

CI/CD & Deploy

• docker compose drives local and production environments
• Production deploys run through the production compose file and migration hooks
• Health checks and supervisor-based worker restarts are built into the operational flow