Skip to content

NASA · 2017–2025

NASA Earth Observatory

A flagship NASA science communication platform serving 1.5M+ monthly visitors — rebuilt so editors ship without waiting on engineering, and the stack stays maintainable for the next decade.

On this page
  1. Snapshot
  2. Platform
  3. Overview
  4. Problem
  5. Decisions
  6. Outcome
  7. Team & leadership
  8. Editorial Velocity & Scale
  9. Publishing Architecture
  10. Accessibility & Performance
Case study NASA · 2017–2025
Monthly visitors
1.5M+
Editorial publishing
Self-serve

Platform

  1. 01 · Author

    Self-serve templates

    Editors compose stories from shared components instead of waiting on a custom engineering build.

    Laravel

  2. 02 · Pipeline

    Imagery pyramids

    Uploads become AVIF/WebP, spatial metadata, and LQIP automatically — not a desktop export ritual.

    Async jobs

  3. 03 · Gate

    508 / WCAG / perf

    Accessibility and frontend budgets are CI quality gates, not a post-launch audit.

    CI/CD

  4. 04 · Deliver

    Edge cache

    Tagged, pre-compressed assets absorb traffic spikes so origin load stays flat.

    CDN

Author → imagery pipeline → CI gates → edge

Outcome

Editors ship routine stories without waiting on custom engineering — throughput became a product of the system, not heroics.

Stack

Role

Lead engineer — owned the platform re-architecture and publishing pipeline, and set the frontend performance and accessibility standards.

Problem

  • Routine stories still needed custom engineering — brittle, one-off publishing patterns made editorial velocity a queue, not a system.
  • Traffic and imagery volume exposed performance, accessibility, and SEO debt that could not be patched story-by-story.
  • Distributed content teams lacked a shared workflow — engineering had become the bottleneck for science communication at scale.

Decisions

  • Standardize on repeatable story templates and a shared publishing model instead of per-story builds — accept slower net-new features to unlock editorial self-service.
  • Treat large imagery, metadata consistency, and non-engineer workflows as first-class pipeline concerns, not afterthoughts bolted onto the CMS.
  • Gate releases on frontend performance, accessibility, and search discoverability so public science traffic and WCAG expectations stay non-negotiable.

Outcome

  • Editors ship routine stories without waiting on custom engineering — throughput became a product of the system, not heroics.
  • High-traffic public science audience got a stronger performance and accessibility baseline.
  • Left a maintainable foundation for ongoing Earth science communication instead of another round of one-off platform debt.

Team & leadership

Leadership mode
Tech lead / sticky IC across platform engineering and editorial partners
Team & partners
~4 engineers and content partners on a flagship site serving 1.5M+ monthly visitors
What I unblocked
Moved story production off one-off engineering work so editors could ship without waiting on custom builds.
Hard decision
Traded short-term feature velocity for a shared publishing model — fewer heroics per story, higher long-term throughput.

Editorial Velocity & Scale

NASA’s Earth Observatory is one of the agency’s highest-traffic public education platforms, delivering satellite imagery, climate data, and explanatory science journalism to over 1.5 million visitors every month.

Over years of organic growth, however, the publishing workflow had become a critical engineering bottleneck:

  • Every new editorial format, custom interactive visualization, or major data story required ad-hoc software engineering support.
  • Ultra-high-resolution satellite images (often 100MB+ TIFF files from MODIS, Landsat, and VIIRS) were manually cropped and exported, leading to inconsistent compression, bloated page weights, and degraded mobile performance.
  • Search discoverability and accessibility compliance (Section 508 / WCAG) were managed reactively rather than enforced systematically at publication time.

Editorial velocity had turned into an engineering queue. My goal as lead engineer was to decouple content production from developer intervention by building a self-service publishing architecture engineered for long-term maintainability.

Publishing Architecture

We restructured the platform into a decoupled publishing system with an automated asset transformation engine:

  1. Self-Service Editorial Templates: Instead of bespoke layouts per article, we developed a modular, component-driven story publishing model. Editorial staff could compose rich narrative layouts, image comparisons (before-and-after flood or wildfire overlays), and data callouts without writing a line of code or filing an engineering ticket.
  2. Automated Imagery Pipeline: Satellite images uploaded by science writers are automatically ingested into an asynchronous image processing pipeline. The pipeline generates responsive AVIF and WebP image pyramids, extracts spatial metadata, and pre-generates lightweight low-quality image placeholders (LQIP) to ensure zero layout shift (CLS).
  3. Edge Caching & Resilience: Serving 1.5M+ monthly visitors across global networks required aggressive edge caching with deterministic cache tags. When breaking disaster imagery or viral astronomical events drove sudden 10x traffic spikes, origin server load remained virtually flat while edge nodes served cached, pre-compressed assets.

Accessibility & Performance

Public science platforms have a civic obligation to be accessible to everyone, across low-bandwidth connections, mobile devices, and assistive technologies:

  • Strict Accessibility Compliance: Accessibility was integrated into CI/CD quality gates. Semantic HTML, keyboard navigability, high-contrast typography, and automated alternate-text requirements ensured compliance with federal Section 508 and WCAG standards.
  • Frontend Budget Discipline: By eliminating third-party script bloat, optimizing font delivery, and relying on lean, modern web standards, First Contentful Paint (FCP) and Largest Contentful Paint (LCP) dropped dramatically across mobile devices.
  • Durable Architecture: By resisting the temptation to rewrite the frontend in a fast-moving, short-lived SPA framework, we delivered a platform that remained stable, fast, and easy for new developers to maintain years into the future.
← All work