Deep Space Research Platform
System Design & Technical Architecture

Vision to Execution

1. Vision & Strategic Intent

1.1 Mission

Build a unified, publicly accessible platform for deep-space scientific research that consolidates real-time telemetry from NASA missions, interstellar object observations, and theoretical cosmology simulations into an integrated analytical and visualization system — while maintaining near-zero operational cost and production-grade reliability.

1.2 Strategic Objectives

1.3 Why This Architecture

The deep-space research domain has a distinctive constraint profile:

• Data is authoritative but unreliable in delivery. NASA APIs return high-quality scientific data but can be intermittent, rate-limited, or structurally changed without notice.
• Computation is bursty, not sustained. Trajectory calculations and plot rendering spike on page load, then idle.
• Users are readers, not writers. The web interface is read-only; data ingestion is operator-initiated.
• Budget is minimal. A research platform should cost less than a coffee subscription to run.

These constraints drove every major architectural decision: server-side rendering over SPA frameworks, SQLite over managed databases, synthetic fallback over hard failures, and a single-instance deployment over distributed systems.

2. Platform Overview

The Deep Space Research Platform comprises five interconnected projects published under a single domain:

┌──────────────────────────────────────────────────────────────────────────┐
│                     prabhusadasivam.com                                  │
│                                                                          │
│  ┌──────────────────────────────────────────────────────────────────┐   │
│  │                  Deep Space Portal                                │   │
│  │   Flask web app · 15 HTML templates · 9 API endpoints            │   │
│  │   Nginx reverse proxy · Gunicorn WSGI · AWS deployment           │   │
│  └─────────┬────────────────────┬───────────────────────┬───────────┘   │
│            │                    │                       │               │
│  ┌─────────┴───────────┐ ┌─────┴───────────────┐ ┌────┴────────────┐   │
│  │   Voyager 1 Suite   │ │  3I/ATLAS Research   │ │  Black Hole     │   │
│  │   4 analysis modules│ │  Jupyter pipeline    │ │  Simulation     │   │
│  │   Trajectory, PWS,  │ │  Ephemerides + MAST  │ │  Bouncing       │   │
│  │   Density, Magneto  │ │  Orbital elements    │ │  cosmology      │   │
│  └─────────┬───────────┘ └──────────┬───────────┘ └───────┬────────┘   │
│            │                         │                       │           │
│            └─────────────┬───────────┘───────────────────────┘           │
│                          ▼                                               │
│              ┌───────────────────────┐                                   │
│              │    Unified Analytics  │                                   │
│              │    Database           │                                   │
│              │    (deep_space_db)    │                                   │
│              └───────────────────────┘                                   │
└──────────────────────────────────────────────────────────────────────────┘

3. System Context & Integration Landscape

3.1 External System Dependencies

                              ┌─────────────────────┐
                              │    prabhusadasivam   │
                              │        .com          │
                              └──────────┬───────────┘
                                         │
         ┌──────────┬──────────┬─────────┼─────────┬───────────┬──────────┐
         ▼          ▼          ▼         ▼         ▼           ▼          ▼
    ┌─────────┐ ┌────────┐ ┌────────┐ ┌──────┐ ┌───────┐ ┌────────┐ ┌──────┐
    │   JPL   │ │  NASA  │ │  NASA  │ │ NASA │ │ NASA  │ │  NOAA  │ │ MAST │
    │HORIZONS │ │  SPDF  │ │  PDS   │ │ NeoWs│ │ DONKI │ │  SWPC  │ │(STScI│
    │         │ │        │ │  PPI   │ │      │ │       │ │        │ │)     │
    └─────────┘ └────────┘ └────────┘ └──────┘ └───────┘ └────────┘ └──────┘
    Trajectory   Magneto-   Plasma     Near-    Solar     Kp Index   HST/JWST
    Ephemerides  meter CDF  Wave CDF   Earth    Flares    Forecast   Archive
                                       Objects  CMEs/GST

Key design decision: Every external dependency has an explicit fallback path. The platform never returns an error page due to upstream API failure.

3.2 Downstream Consumers

4. Architecture Principles

These principles govern all design decisions across the platform:

5. Technology Stack & Decision Rationale

5.1 Stack Overview

5.2 Key Technology Decisions

Why Flask over Django/FastAPI: Django's ORM, admin panel, and auth middleware are unnecessary for a read-only research site. FastAPI's async model adds complexity with no benefit when every request is a synchronous NASA API call followed by matplotlib rendering. Flask provides the minimal surface needed: routing, Jinja2 templates, and request handling.

Why server-side matplotlib over D3.js/Plotly: Scientific plots require precise control over axes, annotations, colormaps, and dual-axis layouts that matplotlib provides natively. Embedding plots as base64 PNGs in JSON responses eliminates JavaScript rendering, client-side library loading, and cross-browser compatibility issues. The trade-off (no client-side interactivity) is acceptable for a research presentation platform.

Why SQLite over PostgreSQL/DynamoDB: The workload is single-writer, read-heavy, and local. SQLite requires no server process, no connection pooling, no credential management, and no monthly cost. WAL mode enables concurrent reads during ingestion. The 281 TB theoretical limit far exceeds projected needs. If multi-user access becomes necessary, the schema is standard SQL and can migrate to PostgreSQL without DDL changes.

Why AWS CLI over boto3 for S3: The backup script needs exactly three operations: upload, list, download. The AWS CLI handles these with subprocess calls, avoiding a boto3 dependency, its transitive dependency tree, and the associated supply chain surface. For a script that runs once per day, the subprocess overhead is negligible.

Why Gunicorn with 2 workers: Each worker handles one request at a time. Matplotlib is not thread-safe, so preload_app=True with sync workers is the correct model. Two workers provide basic concurrency (one can render a plot while the other serves a cached page) without exceeding the 2 GB RAM of a t3.small.

6. Infrastructure Architecture

6.1 Deployment Topology

                              Internet
                                 │
                            ┌────┴────┐
                            │ GoDaddy │
                            │   DNS   │  A: prabhusadasivam.com → Elastic IP
                            └────┬────┘  CNAME: www → prabhusadasivam.com
                                 │
                    ┌────────────┴────────────┐
                    │    AWS EC2 t3.small      │
                    │    Amazon Linux 2023     │
                    │    Elastic IP attached   │
                    │                          │
                    │  ┌────────────────────┐  │
                    │  │      Nginx         │  │
                    │  │  :80 → 301 HTTPS   │  │
                    │  │  :443 → TLS term   │  │
                    │  │  proxy_pass :8000   │  │
                    │  │  security headers   │  │
                    │  │  dotfile deny       │  │
                    │  └─────────┬──────────┘  │
                    │            │              │
                    │  ┌─────────┴──────────┐  │
                    │  │    Gunicorn        │  │
                    │  │  127.0.0.1:8000    │  │
                    │  │  2 sync workers    │  │
                    │  │  systemd managed   │  │
                    │  └─────────┬──────────┘  │
                    │            │              │
                    │  ┌─────────┴──────────┐  │
                    │  │  Flask Application │  │
                    │  │  (deep_space_portal)│  │
                    │  │  15 page routes    │  │
                    │  │  9 API endpoints   │  │
                    │  │  4 utility routes  │  │
                    │  └────────────────────┘  │
                    │                          │
                    └──────────┬───────────────┘
                               │
                    ┌──────────┴───────────────┐
                    │        AWS S3             │
                    │  db-backups/ (versioned)  │
                    └──────────────────────────┘

6.2 Network Security

6.3 Nginx Hardening

# Security headers on every response
X-Frame-Options:           DENY
X-Content-Type-Options:    nosniff
Referrer-Policy:           strict-origin-when-cross-origin

# Deny access to dotfiles (.git, .env, etc.)
location ~ /\. { deny all; }

# Proxy configuration — loopback only
proxy_pass http://127.0.0.1:8000;

6.4 Process Lifecycle

                    Boot
                      │
                      ▼
              systemd starts
         deep_space_portal.service
                      │
                      ▼
              Gunicorn spawns
              2 Flask workers
                      │
              ┌───────┴───────┐
              │               │
           Worker 1        Worker 2
              │               │
              ▼               ▼
         Serve requests  Serve requests
              │
              │ ← Process crash
              ▼
        systemd detects
        exit code ≠ 0
              │
              ▼
        Restart=always
        RestartSec=3
              │
              ▼
        Gunicorn respawns

7. Application Architecture

7.1 Request Flow

Browser GET /trajectory
         │
         ▼
     Nginx (TLS termination, security headers)
         │
         ▼
     Gunicorn → Flask route handler
         │
         ├── render_template("trajectory.html")
         │       ├── nav_caret=True (dropdown nav config)
         │       ├── page-specific meta tags (SEO)
         │       └── Template extends base layout
         │
         └── Template includes <script> that calls /api/trajectory
                    │
                    ▼
              Flask API handler
                    │
                    ├── Try: JPL HORIZONS query (real data)
                    │         │
                    │         ├── Success → matplotlib plot → base64 PNG
                    │         └── Failure ──┐
                    │                       │
                    ├── Fallback: synthetic trajectory model
                    │         │
                    │         └── matplotlib plot → base64 PNG
                    │
                    └── Return JSON:
                          {
                            "plot": "data:image/png;base64,...",
                            "events": [...],
                            "galactic_coords": {...},
                            "data_source": "jpl_horizons" | "synthetic"
                          }

7.2 Rendering Strategy

All visualization follows a consistent server-side rendering pipeline:

1. Data acquisition — Call external API or generate synthetic data
2. Scientific computation — NumPy/SciPy processing (filtering, FFT, ridge detection)
3. Plot generation — Matplotlib with Agg backend (no display server required)
4. Encoding — io.BytesIO → base64 string
5. Transport — JSON response with embedded base64 PNG
6. Display — Jinja2 template sets <img src=""> or JavaScript img.src = data.plot

This approach guarantees:

• Identical rendering across all browsers and devices
• No client-side JavaScript libraries for charting
• SEO-friendly — content is in the initial HTML response
• Cacheable — API responses can be cached at any layer

7.3 Caching Architecture

Design decision: No external cache (Redis, Memcached) is used. The in-memory approach is sufficient for single-instance deployment and eliminates an infrastructure dependency. If scaling to multiple instances, a shared cache layer would be introduced.

7.4 Template Architecture

All 15 page templates plus 2 shared partials (_footer.html, _scroll_top.html) share:

• Dark mission-control theme (#0c0c0c → #1a1a2e → #16213e)
• 3D glassmorphic navigation bar with split-button dropdowns (Voyager 1 · Space Intelligence · Deep Research)
• SEO meta tags (title, description, Open Graph, Twitter Cards, JSON-LD where applicable)
• Consistent <header> → <main> → journey navigation → <footer> structure

Voyager 1 analytical pages are connected through a sequential journey navigation:

Facts → Trajectory → Plasma Waves → Density → Magnetometer → 3I/ATLAS

Each analytical page includes "Previous" / "Next" links, creating a guided research narrative through the data. The home page exposes every section via the hero CTA dropdowns (canonical navigation) and a curated "Where To Go Next" prose pointer rather than a sitemap-style card grid.

7.5 Shared Scientific Models (ADR-002)

A small set of scientific constants — Voyager 1's heliopause anchor (121.0 AU on 2012-08-25), post-heliopause drift rate (3.6 AU/yr), and J2000 pointing direction (RA 17.22 h, Dec 12.08°) — are exposed by a single Python module, voyager1_project/voyager1_position_model.py. Every consumer routes through it.

Why it matters. Consistency of message is a product principle and an architectural one. Two implementations of the same constant inevitably drift; a visitor who notices the inconsistency loses trust in every number on the site. The single-module approach makes drift impossible — a re-anchor against JPL Horizons updates every public surface in one commit. The pattern (constants in one pure-arithmetic module; all consumers import) generalises to any future scientific model the platform exposes.

Validation cadence.

7.6 Architectural Decision Records

ADRs are captured inline in the ticket that introduced them rather than in a dedicated docs/adr/ directory. The current set originated from the dynamic-/facts work and now governs every page that displays a Voyager 1 number.

ADRs 001 and 004 are editorial decisions encoded in code; 002 and 003 are structural and enforced by the test suite (§7.5). When a future decision rises to the level of “we will not revisit this without a written reason”, append it to this table.

8. Data Architecture

8.1 Data Domains

8.2 Unified Database Schema

┌──────────────────────────────────────────────────────────────────┐
│                     deep_space_research.db                        │
│                                                                   │
│  VOYAGER 1 (5 tables)          3I/ATLAS (4 tables)               │
│  ┌────────────────────┐        ┌────────────────────┐            │
│  │ magnetic_field     │        │ ephemerides        │            │
│  │ plasma_wave        │        │ mast_observations  │            │
│  │ electron_density   │        │ orbital_elements   │            │
│  │ trajectory         │        │ datasets           │            │
│  │ events             │        └────────────────────┘            │
│  └────────────────────┘                                          │
│                                                                   │
│  BLACK HOLE (1 table)          SPACE INTEL (2 tables)            │
│  ┌────────────────────┐        ┌────────────────────┐            │
│  │ simulations        │        │ neos               │            │
│  └────────────────────┘        │ solar              │            │
│                                └────────────────────┘            │
│                                                                   │
│  METADATA (3 tables)                                             │
│  ┌────────────────────┐                                          │
│  │ research_insights  │  ← cross-project analytical findings     │
│  │ ingestion_log      │  ← every data load audited               │
│  │ s3_backup_log      │  ← every backup audited                  │
│  └────────────────────┘                                          │
└──────────────────────────────────────────────────────────────────┘

8.3 Schema Design Invariants

8.4 Data Lineage

NASA SPDF → voyager1_magneticfield_nTS_analysis.py → /api/magnetometer → JSON
                                                   ↘
                                                    → init_db.py → voyager1_magnetic_field table
                                                                              ↓
                                                                   s3_backup.py → S3

JPL HORIZONS → astroquery → /api/trajectory → JSON
             → astroquery → 3I_ATLAS_research_notebook.ipynb → ephemerides.csv
                                                              → init_db.py → atlas_3i_ephemerides table

Every data point can be traced from its NASA/JPL origin through the ingestion pipeline to the database row, identified by the source column.

9. API Design & Contract

9.1 API Inventory

9.2 Response Contract

All plot-bearing endpoints follow a consistent contract:

{
  "plot": "data:image/png;base64,...",     // Always present
  "data_source": "jpl_horizons|synthetic", // Always present — transparency
  "statistics": { ... },                    // Domain-specific metrics
  "events": [ ... ]                         // Optional: notable data points
}

The data_source field is critical to architectural integrity: it tells the consumer whether they are viewing real NASA data or a synthetic approximation. This transparency extends the provenance principle from the database layer to the API layer.

9.3 Error Handling Contract

API endpoints never return HTTP 5xx. The degradation hierarchy is:

1. Real data (preferred) — external API succeeded
2. Cached data — external API failed, in-memory cache is fresh (< 15 min)
3. Stale cache — external API failed, cache is stale but usable
4. Synthetic data — no cache available; generate mathematically plausible data
5. Empty response with explanation — only if generation itself fails (extremely rare)

10. Cross-Project Integration Strategy

10.1 Integration Architecture

┌──────────────┐    File System     ┌──────────────┐
│  3I/ATLAS    │ ──── CSVs/JSONs ──►│  deep_space  │
│  Research    │                     │      _db     │
└──────┬───────┘                     └──────────────┘
       │                                    ▲
       │ PNGs to Images/                    │ CSVs/JSONs
       ▼                                    │
┌──────────────┐                     ┌──────┴───────┐
│  Voyager 1   │ ◄── imports ───────│  Deep Space   │
│  (science)   │                     │  Portal       │
└──────────────┘                     └──────────────┘
       │                                    │
       │                                    │ Serves all pages under one domain
       ▼                                    ▼
  Analysis outputs              prabhusadasivam.com

10.2 Integration Design Rationale

Projects are deliberately not microservices. A monolithic Flask application (the portal) serves all pages because:

• There is one operator, one deployment target, one domain
• Cross-project pages share navigation, styling, and SEO configuration
• The complexity cost of inter-service communication exceeds the benefit at this scale
• Adding a new research project is a single Flask route + template — no new infrastructure

The key architectural improvement is that science modules are now decoupled from presentation. Voyager 1 analysis scripts can be used as CLI tools, imported into Jupyter notebooks, or called by the portal — without carrying Flask/Gunicorn dependencies.

This will be revisited if the platform requires multi-team development or independent scaling (see §17).

11. Resilience & Graceful Degradation

11.1 Failure Mode Analysis

11.2 Synthetic Data Architecture

The synthetic data generators are not test mocks — they are mathematically grounded models:

11.3 Resilience Principle

The platform renders every page, every time. No combination of external failures produces a user-facing error. The quality of data may degrade (real → cached → synthetic), but the experience never breaks.

12. Security Architecture

12.1 Defense in Depth

Layer 1: Network
├── Security group: SSH restricted to operator IP
├── HTTP/HTTPS open (required for public website)
└── Gunicorn bound to 127.0.0.1 only

Layer 2: TLS
├── Let's Encrypt certificate (auto-renewal)
├── HTTP → HTTPS redirect (Nginx)
└── HSTS implied by redirect

Layer 3: Nginx
├── X-Frame-Options: DENY
├── X-Content-Type-Options: nosniff
├── Referrer-Policy: strict-origin-when-cross-origin
├── Dotfile access denied (blocks .git, .env)
└── /api/ disallowed in robots.txt

Layer 4: Application
├── Flask debug mode off by default (env-var gated)
├── SECRET_KEY via environment variable (secure random fallback)
├── flask-limiter: 10 req/min on all /api/* endpoints
├── Path traversal blocked: rejects '..' in image filenames
├── SRI integrity hashes on all CDN resources (KaTeX)
├── No user input to SQL queries (read-only web interface)
├── Parameterized SQL in all ingestion scripts
└── NASA API key via environment variable

Layer 5: Data
├── SQLite WAL mode (crash consistency)
├── Source provenance on every row
├── .gitignore excludes .db files and .env
└── No PII in any data table

Layer 6: Cloud
├── S3 bucket: all public access blocked
├── S3 versioning: protects against deletion
├── S3 SSE-S3: encryption at rest
├── IAM: scoped credentials recommended
└── AWS CLI: HTTPS enforced for all S3 operations

12.2 Secrets Inventory

No secrets exist in any committed file across all four repositories.

12.3 STRIDE Threat Model

A complete STRIDE analysis is documented separately, covering 14 identified threats across Spoofing, Tampering, Repudiation, Information Disclosure, DoS, and Elevation of Privilege — with trust boundary diagrams, asset inventory with CIA ratings, attack surface assessment, and incident response playbooks.

13. Scalability & Growth Strategy

13.1 Current Capacity

13.2 Scaling Triggers & Responses

13.3 What Will NOT Change

These are architectural invariants that hold regardless of scale:

• Server-side plot rendering — matplotlib's scientific fidelity is not replaceable by JavaScript charting
• Data provenance on every row — source and ingested_at columns are non-negotiable
• Graceful degradation — synthetic fallback remains the failure strategy
• Standard SQL — no ORM, no SQLite-specific syntax, migration-ready at all times
• Single source of truth for shared scientific constants (ADR-002) — Voyager 1's heliopause anchor, drift rate, and pointing direction live in exactly one Python module; every consumer imports. The pattern generalises to any future shared scientific model.

14. Operational Excellence

14.1 Deployment Model

14.2 Database Operations

14.3 Observability

15. Risks, Constraints & Trade-Offs

15.1 Architectural Trade-Offs

15.2 Technical Debt Register

Resolved (recently): A 72-test pytest regression suite (deep_space_portal/tests/) now covers route smoke tests, voice/structure integrity for the home page, the Voyager 1 position model bound check, and endpoint agreement between the synthetic trajectory and the shared position helper. Run on every commit before deploy.

15.3 Constraints

16. Roadmap & Evolution Path

Phase 1 — Foundation (Complete)

• Flask web application — 15 page routes, 9 API endpoints, 4 utility routes
• Real-time NASA/JPL data integration with synthetic fallback on every external source
• Voyager 1 analytical suite: facts, trajectory, plasma waves, electron density, magnetometer
• Voyager Story long-form narrative page (/voyager-story)
• Single source of truth for Voyager 1 position (ADR-002) — voyager1_position_model.py consumed by /facts, /, /trajectory, and verify_voyager_position.py
• Dynamic /facts page with calibrated linear position model and annual JPL Horizons reconciliation
• Space Intelligence (NEOs + space weather), Orbital Density, Live Orbit 3D
• 3I/ATLAS Jupyter research pipeline
• Black hole bouncing cosmology simulation
• Mars 1993 mission page; AI-index structured knowledge page; this Architecture page
• 72-test pytest regression suite (routes, voice, position model, end-point agreement)
• Unified SQLite analytics database (15 tables)
• S3 backup with versioning and audit logging
• EC2 deployment with Nginx, Gunicorn, HTTPS, systemd
• Security threat model and architecture documentation

Phase 2 — Operational Maturity

• Automated backup schedule (cron/Task Scheduler)
• CI/CD pipeline (GitHub Actions → EC2)
• Uptime monitoring (Route 53 health check or UptimeRobot)
• Replace root AWS credentials with scoped IAM user
• Quarterly drift-telemetry job: append (date, horizons_au, model_au, Δ) to a CSV (currently manual; see §7.5)

Phase 3 — Data Pipeline Automation

• Scheduled ingestion from Flask /api/* endpoints into database
• Space intelligence data persistence (NEOs, solar events)
• Staleness detection and alerting on aged data
• Data quality dashboards in Jupyter

Phase 4 — Analytics & Insights

• Parquet export for S3/Athena serverless queries
• Cross-project anomaly detection (magnetic field × solar activity)
• Research insight timeline visualization
• Streamlit or Jupyter dashboard for interactive analysis

Phase 5 — Scale (If Warranted)

• CloudFront CDN for static assets and plot caching
• PostgreSQL migration for multi-user access
• Flask Blueprints for project-specific modules
• Multi-AZ deployment for high availability

17. Appendix — Reference

A. Repository Map

B. External API Reference

C. Key Configuration Files

D. Related Documentation