DepthSync: Real-Time Collaborative Seismic Data Processing in Rust

The Problem: Geoscience Teams Working in Silos

Seismic interpretation has a collaboration problem. Geoscientists working with subsurface volumetric data — stored in formats like OpenVDS (Volumetric Data Store) — typically work on isolated workstations with expensive proprietary software. When they need to share findings, they export static images or PDF reports, losing the interactive context that makes the data meaningful.

This workflow creates bottlenecks. Senior interpreters can't review junior work in real-time. Field teams can't collaborate with office-based geophysicists. And every handoff between team members means re-loading multi-gigabyte datasets from scratch.

DepthSync was built to solve this: a web-based platform where geoscience teams can collaboratively view, annotate, and interpret seismic data in real-time.

Why Rust: Performance Without Compromise

The first technical decision was the most consequential. OpenVDS files use sophisticated compression — wavelet-based algorithms optimized for volumetric data. The reference C++ implementation works, but it's designed for batch processing, not the real-time streaming that a collaborative web application demands.

We chose Rust for the decompression engine for three reasons:

1. Performance — Rust compiles to native code with zero runtime overhead. Our decompressor achieves sub-millisecond decompression per VDS brick, enabling smooth viewport navigation through gigabyte-scale volumes.

2. Memory safety — Seismic data files come from diverse sources with varying quality. Rust's ownership model prevents the buffer overflows and use-after-free bugs that plague C/C++ parsers processing untrusted data.

3. Concurrency — Rust's async runtime and thread-safety guarantees let us decompress multiple bricks in parallel across CPU cores, scaling throughput linearly with hardware.

The Decompression Pipeline

The custom decompressor implements the VDS brick format specification with several optimizations:

• Memory-mapped I/O for zero-copy file access — the OS handles paging, eliminating redundant memory copies
• SIMD instructions for parallel decompression of wavelet coefficients
• Brick caching with LRU eviction tuned to the typical navigation patterns of seismic interpreters
• Streaming architecture that begins sending partial results before full decompression completes

Collaborative Editing: CRDTs for Seismic Data

The collaborative layer was the second major engineering challenge. Real-time editing systems like Google Docs use Operational Transformation (OT), but OT assumes a central server that can serialize all operations. For geoscience teams working in remote field locations with unreliable connectivity, we needed something more resilient.

DepthSync uses CRDTs (Conflict-free Replicated Data Types) for its annotation and interpretation layers. CRDTs guarantee that concurrent edits from multiple users will always converge to the same state, regardless of network ordering or temporary disconnections.

This means a geoscientist can mark a horizon interpretation while offline, and when they reconnect, their work merges automatically with changes made by colleagues — no conflicts, no lost work.

WebSocket Synchronization

The real-time communication layer uses WebSocket connections with a custom binary protocol optimized for the types of operations common in seismic interpretation:

• Viewport updates — compact messages indicating which data slice each user is viewing
• Annotation operations — CRDT operations for horizon picks, fault traces, and free-form annotations
• Presence indicators — showing where each team member is currently looking in the volume

Lessons from the SEG-Y Era

DepthSync builds directly on our earlier work with SEG-Y seismic data parsing. That project taught us the nuances of legacy geoscience data formats — the inconsistencies between format versions, the obscure floating-point representations (IBM HFP), and the importance of performance when dealing with large scientific datasets.

The OpenVDS work takes those lessons further. Where SEG-Y is a sequential trace format, VDS is a multi-dimensional volumetric format with sophisticated compression. The jump from JavaScript-based SEG-Y parsing to Rust-based VDS decompression reflects both the increased performance requirements and our commitment to using the right tool for each job.

See our earlier SEG-Y visualization work →