The Architecture: ISRO as the Foundational Layer
Think of the Indian Space Research Organisation (ISRO) not just as a government agency, but as the foundational layer of a distributed system. For decades, ISRO has been the monolithic service provider, handling everything from R&D to launch operations. When the sector opened to private players in 2020, it effectively started exposing APIs to this monolith. Skyroot Aerospace, with its Vikram-1, is one of the first significant clients to consume these services.
The current architecture looks something like this:
ISRO provides the shared infrastructure: the Satish Dhawan Space Centre, the tracking networks, the deep institutional knowledge, and the regulatory framework. Skyroot built its application—the Vikram-1 rocket, designed to carry up to 350 kilograms into low-Earth orbit—on top of this. This is a classic platform play, where a large, established entity provides the stable, high-cost components, letting smaller, agile players innovate on the application layer. It's a smart way to bootstrap an ecosystem.
The Bottleneck: Resource Contention and the Talent Pool
The immediate success of Vikram-1 is fantastic, but it also highlights an emerging bottleneck: shared resources. We're already seeing discussions about an "exodus of scientists" from ISRO to the private sector. While some see this as "ISRO's loss is India's gain," from an architectural standpoint, it's a resource contention problem.
If ISRO is the stable, highly reliable core service, and private startups are rapidly scaling microservices, then the talent pool—especially specialized aerospace engineers and scientists—is a finite, shared resource. If too many experts migrate without a solid knowledge transfer mechanism or a new talent pipeline, the core service itself could degrade. About individual companies is about the stability of the entire system. You can't have a thousand microservices if your database team is constantly shrinking.
Another potential bottleneck is the physical launch infrastructure. While ISRO has capacity, 400+ startups all vying for launch windows and test facilities will quickly lead to a "Thundering Herd" problem. Without clear scheduling, resource isolation, and potentially new, privately-owned infrastructure, the very success of the private sector could choke its growth.
The Trade-offs: Availability vs. Consistency in Orbit
This shift to private space launches forces a fundamental architectural trade-off, straight out of the CAP theorem: are we optimizing for Availability (AP) or Consistency (CP)?
Historically, ISRO has operated as a CP system. Every launch is meticulously planned, highly consistent in its success rate, but inherently slower and less available due to the centralized control and rigorous processes. The introduction of private players, especially those focused on the small-satellite market, pushes the system towards AP. We want more launches, more frequently, from more providers—higher availability of launch services.
But what about consistency? Consistency here means the reliability of the launch, the predictability of orbital insertion, and the adherence to safety protocols. If the drive for rapid iteration and cost reduction in the private sector leads to a decrease in the consistency of success rates, or worse, an increase in orbital debris from failures, the long-term health of the entire ecosystem suffers.
The challenge is finding the right balance. You can't have a highly available system if its data—in this case, successful orbital deployments—is inconsistent.
The Pattern: A Federated Platform with Clear Contracts
To avoid these bottlenecks and manage the trade-offs, India's private space sector needs to evolve into a more explicitly federated platform architecture. ISRO should formalize its role as a platform provider, offering well-defined services and enforcing clear architectural contracts.
Here's what that might look like:
- Standardized Interfaces: ISRO needs to define clear, versioned APIs for critical services like launch slot reservation, telemetry data ingestion, and regulatory compliance checks. These APIs must be idempotent where applicable. If a private company tries to book a launch slot twice due to a network glitch, the system shouldn't double-book or fail; it should simply confirm the existing booking.
- Resource Isolation: As private infrastructure like launch pads and tracking stations emerge, ISRO's role shifts from sole provider to orchestrator and standard-setter. It needs to ensure that private infrastructure meets certain reliability and safety standards, acting as a certification authority.
- Talent Pipeline: The "exodus" isn't inherently bad, but it means ISRO needs to invest heavily in its own talent pipeline and knowledge management systems. It could even offer training and certification programs that benefit the entire ecosystem, acting as a shared educational resource.
- Data Consistency: For critical shared data, like orbital debris tracking or frequency allocation, strong consistency is non-negotiable. This means a centralized, highly reliable data store, perhaps managed by ISRO, that all private players query and contribute to. For less critical, internal operational data, eventual consistency might be acceptable for private companies.
This isn't about ISRO controlling everything; it's about ISRO providing the stable, well-defined platform that lets private innovation flourish without introducing systemic instability.
The Real Challenge Ahead
The Vikram-1 launch is a fantastic first step, a successful proof-of-concept for India's private space sector. But the real architectural challenge isn't just building more rockets; it's building a resilient, scalable, and economically viable ecosystem. This means moving beyond the initial excitement to define clear architectural contracts, manage shared resources effectively, and make deliberate trade-offs between availability and consistency. India has shown it can build the components; now it needs to build the distributed system that can truly compete on a global scale.
