System Architect

Job Title- Distributed Systems Architect

Location- Mumbai

Mode- Onsite

Job Type: Full-Time

Role Overview

The Distributed Systems Architect is responsible for defining and owning the end-to-end system architecture of the Indic Speech AI platform. This role establishes the structural foundations that allow the platform to deliver real-time speech recognition and speech synthesis at national scale, across multiple languages, with strict latency, reliability, and scalability requirements.

The role is accountable for architectural correctness under normal operation, peak load, partial failure, and long-term evolution. It defines the system invariants that all teams must build against, including control-plane and data-plane separation, fault containment, scalability boundaries, and service interaction models.

This role exists to ensure that the platform can grow in users, languages, traffic volume, and product surface without repeated redesigns or systemic fragility.

Core Responsibilities

The role defines the overall distributed architecture of the Indic Speech AI platform, including how real-time audio flows from edge clients through routing layers to language-specific inference clusters and back.

The role establishes and enforces strict separation between control plane and data plane. Control plane services include authentication, authorization, routing decisions, quota enforcement, configuration, and orchestration. Data plane services include real-time audio streaming, inference execution, and response streaming. This separation is mandatory to ensure that control-plane instability never impacts speech latency.

The role designs the system for horizontal scalability, ensuring that all critical paths scale linearly with traffic and do not introduce shared bottlenecks. Statelessness is enforced wherever possible, and where state is unavoidable, state ownership, lifecycle, and failure behaviour are explicitly defined.

The role defines failure isolation boundaries so that failures in one language, one model version, one availability zone, or one subsystem do not cascade across the platform. This includes defining blast-radius limits and recovery semantics.

The role standardizes the use of distributed systems resilience patterns, including idempotency, circuit breakers, timeouts, retries with backoff, bulkheads, load shedding, and graceful degradation. These patterns are not optional and must be applied consistently across services.

The role anticipates peak traffic scenarios, including national-scale concurrent usage spikes, and ensures that system behaviour under overload is predictable and controlled rather than chaotic.

The role reviews and approves low-level designs (LLDs) for critical services to ensure alignment with architectural principles and long-term platform goals.

Operational Ownership

The Distributed Systems Architect owns the architectural failure modes of the platform. When systemic issues occur, such as cascading failures, uncontrolled latency amplification, or cross-service instability, this role is accountable for identifying architectural root causes and driving corrective changes.

The role owns the definition of architectural guardrails, including what classes of designs are disallowed even if they appear to work locally.

The role is responsible for ensuring that architectural decisions are documented clearly enough to be executable by multiple teams over time.

Key Interfaces

This role works closely with the Technical Governance Lead to ensure architectural decisions are enforced consistently and do not erode over time.

The role interfaces deeply with Core Java, Platform & Networking, GPU Inference, Kubernetes Orchestration, and GitOps & Reliability roles to ensure that architectural intent translates correctly into implementation and operations.