0002 - Mission Service as Talos Backend
| Classification | CONFIDENTIAL |
| Organization | DroneUp |
| Date | April 2026 |
| Status | Pending |
Decision
All new Talos backend APIs (authorization, pilot profiles, drone registry, jurisdictions) will be implemented as a new talos package inside the existing Mission Service, using its existing Cloud SQL database with new tables.
Context
The team needed a backend home for Talos CRUD APIs. Three options were discussed:
| Option | Pros | Cons |
|---|---|---|
| New standalone service + new DB | Clean separation, independent deployment | Requires new Cloud SQL, new CI/CD, new service account, new networking — slow |
| New package in Mission Service | Database already exists, deployment pipeline exists, team knows the codebase | Couples Talos to Uncrew service boundary |
| Extend existing Mission Service packages | Zero new code structure | Pollutes existing Uncrew domain logic |
The team chose new package in Mission Service because:
- Database and deployment infrastructure already exist
- No new Cloud SQL provisioning, IAM, or CI/CD setup needed
- The
talospackage is isolated — can be extracted later if needed - Speed is the priority for the demo phase
Consequences
- New database migrations live under the
talospackage - gRPC service registration adds Talos endpoints to Mission Service’s existing server
- If Talos becomes a standalone product, the
talospackage can be extracted into its own service with a database migration
Last updated on