mohammad-niyas/video-streaming-microservices

Purpose and topology

A Go microservices video platform: REST clients use the API gateway for authentication and video management, while HLS media is served separately. Internal auth/video calls use gRPC; PostgreSQL persists independent auth and video domains; local filesystem storage holds raw uploads and generated HLS assets.

Process entry points

Each deployable starts independently from its service root:

• REST gateway: api-gateway/main.go

• Auth gRPC server: auth-service/main.go

• Video gRPC server: video-service/main.go

• HLS HTTP server: streaming-service/main.go

Environment files exist per service and supply ports, database connectivity, JWT secret, and service addresses.

API gateway boundary

The gateway owns public REST routing, request adaptation, and client-facing authentication enforcement. Routes dispatch to auth and video controllers; gateway gRPC clients call the internal services.

• api-gateway/routes/routes.go

• api-gateway/controllers/auth_controller.go

• api-gateway/controllers/video_controller.go

• api-gateway/config/grpc_client.go

• api-gateway/middleware/auth.go

Flow: client REST request → gateway JWT middleware where required → controller → generated gRPC client → internal service response mapped back to HTTP.

Authentication service

Auth is a gRPC domain service for registration/login and token-oriented authentication behavior. It separates transport/controller logic, application service logic, and PostgreSQL persistence of users.

• auth-service/controllers/auth_controller.go

• auth-service/service/auth_service.go

• auth-service/repository/user_repo.go

• auth-service/models/user.go

• auth-service/config/db.go

JWT/interceptor middleware provides the security boundary around service calls:

• auth-service/middleware/jwt.go

• auth-service/middleware/interceptor.go

Video ingestion and metadata

Video service exposes the video gRPC contract, manages video records in its own PostgreSQL database, and owns media processing/storage. Upload/control requests pass through the controller and repository/model layers; FFmpeg transforms raw video into HLS playlists and transport-stream segments.

• video-service/controllers/video_controller.go

• video-service/repository/video_repo.go

• video-service/models/video.go

• video-service/service/ffmpeg.go

• video-service/config/db.go

The filesystem boundary is explicit: raw source files reside under video-service/storage/raw, while streamable output is under video-service/storage/hls.

Streaming delivery

The streaming service is a distinct HTTP delivery plane rather than a gateway-routed gRPC service. It resolves video IDs and segment names into HLS playlist/segment files and returns them directly to clients.

• streaming-service/main.go

• streaming-service/controllers/stream_controller.go

• streaming-service/config/config.go

• video-service/storage/hls/3/index.m3u8

This separation keeps media-byte delivery outside the authenticated metadata/control API. Current stored HLS artifacts demonstrate per-video directories containing index.m3u8 and .ts segments.

Contracts and dependencies

Protobuf-generated stubs are duplicated at consumer/service boundaries and define the gateway-to-service RPC contracts:

• auth-service/proto/auth.proto

• api-gateway/pkg/pb/auth/auth_grpc.pb.go

• video-service/proto/video.proto

• api-gateway/pkg/pb/video/video_grpc.pb.go

Material runtime dependencies are Go, Gin-based HTTP handling, gRPC/Protobuf, GORM with PostgreSQL, FFmpeg for transcoding, JWT signing/validation, and HLS-compatible clients.