Deep Space Research Platform
Software Architecture

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 four interconnected projects published under a single domain:

┌──────────────────────────────────────────────────────────────────────────┐
│                     prabhusadasivam.com                                  │
│                                                                          │
│  ┌─────────────────────┐  ┌─────────────────────┐  ┌────────────────┐   │
│  │   Voyager 1 Suite   │  │   3I/ATLAS Research  │  │  Black Hole    │   │
│  │   6 analysis pages  │  │   Jupyter pipeline   │  │  Simulation    │   │
│  │   7 API endpoints   │  │   Ephemerides + MAST │  │  Bouncing      │   │
│  │   11 HTML templates │  │   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 │  │
                    │  │  11 page routes    │  │
                    │  │  7 API endpoints   │  │
                    │  │  2 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
            voyager1.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 11 HTML templates share:

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

Pages are connected through a sequential journey navigation:

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

Each page includes "Previous" / "Next" links, creating a guided research narrative through the data.

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   │ ──── CSVs ────────►│  Black Hole  │
│  Web App     │                     │  Simulation  │
└──────────────┘                     └──────────────┘
       │
       │ Serves all pages under one domain
       ▼
  prabhusadasivam.com

10.2 Integration Design Rationale

Projects are deliberately not microservices. A monolithic Flask application 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

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=False in production
├── SECRET_KEY via environment variable
├── 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

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

15.3 Constraints

16. Roadmap & Evolution Path

Phase 1 — Foundation (Complete)

• Flask web application with 11 pages and 7 API endpoints
• Real-time NASA/JPL data integration with synthetic fallback
• 3I/ATLAS Jupyter research pipeline
• Black hole bouncing cosmology simulation
• 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
• Flask route integration tests

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