Microservices Topology
Relevant source files
The following files were used as context for generating this wiki page:
The Microservices Topology of the TAMV Online project defines the structural arrangement and communication patterns of the various independent components that constitute the "most ambitious system created by a single human mind." This architecture is designed to handle high-concurrency audio and video processing while maintaining strict isolation between functional domains. The topology focuses on scalability, fault tolerance, and a centralized entry point for all client-side interactions.
Sources: README.md:2, docs/architecture/topology.md:5-12
System Architecture Overview
The system follows a tiered microservices approach where external requests are filtered through an edge layer before reaching the internal business logic. This separation ensures that internal services, such as the media processing engine and user management, are not directly exposed to the public internet.
Network Segmentation
The topology is divided into three primary zones:
- The Edge Zone: Contains the API Gateway and Load Balancer.
- The Service Mesh: Contains the core logic services (Auth, Stream, Inventory).
- The Data Persistence Zone: Contains isolated database instances for each service.
Sources: infra/docker-compose.yaml:10-45, docs/architecture/topology.md:15-20
The diagram above illustrates the top-down flow from the external client through the centralized gateway to the specific microservices and their respective data stores.
Sources: docs/architecture/topology.md:22, infra/docker-compose.yaml:50-80
Key Components and Responsibilities
The topology is comprised of several specialized services, each responsible for a single aspect of the TAMV ecosystem.
| Component | Function | Communication Protocol |
|---|---|---|
| API Gateway | Request routing, SSL termination, and rate limiting. | HTTPS / gRPC |
| Auth Service | Identity management and JWT issuance. | REST |
| Stream Engine | Real-time audio/video packet processing. | WebSockets / UDP |
| Metadata API | Management of media assets and user profiles. | REST |
Sources: src/shared/config/services.yaml:4-25, src/gateway/conf.d/default.conf:1-15
Service Discovery and Routing
Routing is handled via a reverse proxy mechanism defined in the gateway configuration. The gateway interprets incoming URL patterns and proxies them to the internal service discovery names provided by the container orchestration layer.
Routing Logic
- Requests to
/api/v1/auth/*are forwarded to the Auth Service on port 8081. - Requests to
/api/v1/stream/*are forwarded to the Stream Engine on port 8082. - Static assets are served directly from the edge cache or the Metadata API.
Sources: src/gateway/conf.d/default.conf:18-35, src/shared/config/services.yaml:30-42
This sequence diagram shows the interaction between the client and the internal services via the gateway, highlighting the centralized authentication check before reaching the streaming logic.
Sources: docs/architecture/topology.md:45-60, src/gateway/conf.d/default.conf:40-55
Infrastructure Implementation
The topology is instantiated using a containerized environment where each service resides in its own network namespace.
# Simplified topology representation from infra/docker-compose.yaml
services:
gateway:
image: tamv/gateway:latest
ports:
- "443:443"
networks:
- public
- private
auth-service:
image: tamv/auth:latest
networks:
- private
Sources: infra/docker-compose.yaml:5-25
The persistence layer is strictly decoupled. The Auth Service utilizes a dedicated instance to prevent cross-service data leakage, while the Stream Service relies on a Redis-backed high-speed cache for session management and packet buffering.
Sources: infra/docker-compose.yaml:85-110, src/shared/config/services.yaml:50-60
Summary
The TAMV Online Microservices Topology provides a robust framework that balances security and performance. By utilizing a centralized API Gateway and strictly defined internal networks, the system ensures that the "ambitious" requirements of audio/video transmission are met with high reliability and modularity. This structure allows for independent scaling of the Stream Engine without affecting the availability of the Metadata or Auth services.
Sources: README.md:1-3, docs/architecture/topology.md:100-105