Nanopore/Illumina sequencers stream reads into cloud pipelines in real time via Kafka
Modern sequencers no longer treat basecalling as an offline batch step performed after a run finishes. Oxford Nanopore instruments running MinKNOW stream raw ionic-current "squiggles" through an embedded or attached GPU basecaller (Guppy, now largely superseded by Dorado) the instant each read completes translocation. Illumina platforms perform an analogous real-time conversion of optical images to bases via Real-Time Analysis (RTA) as each sequencing cycle completes, so downstream systems can begin consuming sequence data within seconds of signal acquisition rather than hours.
As a single-stranded DNA or RNA molecule is ratcheted through a protein nanopore (the CsgG-derived or MspA-family pore embedded in a membrane across each sensor well), it modulates an ionic current flowing through that pore. The instrument's ASIC samples this current at roughly 4–5 kHz, producing a continuous "squiggle" trace unique to the local sequence context spanning the pore's sensing region (typically 5–6 nucleotides at a time).
Rather than storing raw squiggles for later processing, MinKNOW streams each read's current trace directly into a neural-network basecaller. Dorado, Oxford Nanopore's current-generation basecaller, uses a convolutional/transformer hybrid architecture trained end-to-end to map signal windows to base probabilities, emitting a FASTQ or unaligned BAM record with per-base quality scores within a fraction of a second of the read finishing translocation.
Because each of the flow cell's up to 512 active channels operates independently and in parallel, the instrument produces a continuous, multiplexed stream of newly completed reads throughout the run — exactly the kind of continuous emission that a streaming ingestion architecture is built to consume, as opposed to the single large batch file produced by legacy end-of-run basecalling.
Illumina's sequencing-by-synthesis (SBS) chemistry works fundamentally differently but yields the same streaming opportunity. Fluorescently labeled, reversibly terminated nucleotides are incorporated one cycle at a time across millions of clonally amplified clusters on a flow cell; a camera images the entire flow cell after each cycle, and software identifies which of four dye colors (or two-channel/one-channel encodings on newer instruments) each cluster displays.
Real-Time Analysis (RTA), running on the sequencer's onboard compute, converts these per-cycle images into base calls and quality scores as each cycle completes — it does not wait for the full 150–300 cycle run to conclude. Base call files (BCLs) accumulate cycle by cycle, and on instruments such as the NovaSeq X, onboard secondary analysis can begin converting BCL to FASTQ and streaming reads outward well before the final cycle is imaged.
This cycle-by-cycle emission is the Illumina analogue of Nanopore's per-read streaming: both platforms produce sequence data as a continuous flow rather than a single terminal artifact, which is the precondition for everything that follows in a real-time ingestion pipeline.
MinKNOW is the control software that orchestrates a Nanopore run end to end: it manages flow-cell voltage, tracks pore health, invokes the basecaller, and exposes completed reads to downstream software through a local streaming API almost immediately after each read finishes. Because basecalling happens live, MinKNOW can also implement "Read Until" adaptive sampling — for each read, a short signal prefix is basecalled and aligned in real time against a target or exclusion reference; if the read does not match the desired region, the pore voltage is briefly reversed to eject the strand and free the channel for a new molecule.
Because basecalling and alignment both run within milliseconds of signal acquisition, adaptive sampling can enrich for a target region or deplete unwanted host DNA on the fly — effectively performing selective sequencing without any additional wet-lab enrichment step, a capability that is only possible because the pipeline is real-time end to end.
Once a read is base-called, it is serialized into a compact record and published to an Apache Kafka topic that has been partitioned across multiple brokers. This step decouples the sequencer from every downstream consumer: the instrument simply produces records as fast as reads complete, while QC, alignment, and dashboard services subscribe independently, at their own pace, with Kafka acting as a durable, replayable buffer between the two.
A Kafka topic is a durable, append-only log split into partitions, each of which is an independently ordered sequence of records replicated across a configurable number of brokers. For sequencer ingestion, a natural partitioning key is the flow-cell channel ID or a hash of the read ID: this spreads reads roughly evenly across partitions while preserving per-channel ordering, which matters if downstream consumers need to reconstruct per-pore signal history.
Each partition can be consumed independently, so the degree of parallelism available to downstream QC and alignment services is bounded by the partition count chosen at topic-creation time — this is precisely why "Consumer Parallelism" in a streaming genomics pipeline is a first-class tunable: too few partitions starve otherwise-idle consumer instances, while too many adds coordination overhead without added throughput.
Producers (the code running alongside MinKNOW or RTA) write records asynchronously, batching several reads together before each network send to amortize per-request overhead, and Kafka brokers append these batches to the partition log on disk, immediately making them available to any subscribed consumer group.
Each streamed record typically carries a read identifier, channel/well number, run ID, the called sequence, per-base quality string, and basecaller metadata, encoded with a compact binary schema (Avro or Protobuf) rather than raw FASTQ text — this both shrinks message size and lets the schema evolve without breaking existing consumers via a schema registry.
Two producer settings directly trade latency against throughput: linger.ms controls how long the producer waits to accumulate a fuller batch before sending (larger values improve compression and network efficiency but add latency), and compression.type (commonly zstd for genomic text data, which compresses FASTQ-like sequences 3–4× before transmission) reduces the bytes that must cross the network and be stored. For a high-output flow cell producing hundreds of reads per second, tuning these parameters keeps end-to-end latency in the tens of milliseconds while still achieving near-linear throughput scaling as more partitions and brokers are added.
Before message-queue-based ingestion became common, real-time sequencing pipelines relied on watching a directory for new FASTQ or BCL files and triggering downstream jobs on file-close events — a brittle pattern prone to race conditions, partial reads, and no built-in replay if a downstream service crashed mid-run.
Kafka's log-structured storage with configurable retention (commonly 7 days for sequencing pipelines) means that if a QC or alignment consumer crashes or is redeployed, it simply resumes from its last committed offset — no reads are lost and none need to be re-basecalled. Multiple independent consumer groups (QC, alignment, dashboard aggregation, long-term archival) can all read the same topic at their own pace without interfering with one another, which is not naturally possible with a single-writer, single-reader filesystem watch pattern.
A 7-day retention window means an entire multi-day nanopore run can be fully replayed from Kafka into a corrected pipeline after a bug fix — without touching the sequencer or re-running any wet-lab step, something impossible with the transient, overwrite-prone file-polling architectures it replaces.
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Apache Kafka | Partitioned log, pull-based consumers | Durable disk-backed log, configurable retention, consumer-group offset tracking | Best replay/durability trade-off; industry default for genomic streaming |
| AWS Kinesis Data Streams | Managed shard-based stream | Similar partition model (shards), fully managed, tight AWS ecosystem integration | Low ops overhead for cloud-native pipelines |
| Apache Pulsar | Segmented log + built-in pub/sub | Separates compute (brokers) from storage (BookKeeper), multi-tenant topics | Elastic scaling and geo-replication out of the box |
| Filesystem polling (legacy) | Watch directory for closed files | Cron/inotify triggers on file-close events, single consumer typical | Simple, but no replay, no parallelism, race-condition prone |
A streaming consumer group attached to the Kafka topic computes per-read quality metrics the instant each record arrives — mean Phred quality, read length, adapter content — and discards reads that fall below configured thresholds before they ever reach the aligner. This keeps compute spent on alignment proportional to useful data, and prevents low-quality noise from degrading downstream coverage and variant-calling statistics.
Each basecalled read arrives with a per-base Phred quality string already computed by the basecaller's output-probability layer, where a quality score Q relates to basecall error probability p by Q = −10·log₁₀(p): a Q10 base has a 1-in-10 chance of being wrong, Q20 a 1-in-100 chance, and Q30 a 1-in-1000 chance. A streaming QC consumer aggregates these per-base values into a mean read quality, checks total read length against a minimum (commonly 200–500 bp to exclude fragments unlikely to align uniquely), and scans read ends for residual sequencing adapter that survived basecalling trimming.
Unlike batch tools such as NanoFilt or Filtlong that process an entire completed FASTQ file at once, a streaming equivalent evaluates this logic per record as it is consumed from Kafka, in well under a millisecond, immediately committing an offset and either forwarding the record to an "aligner-ready" downstream topic or dropping it with a logged reason code — no read is held waiting for a batch window to close.
Kafka consumer groups allow multiple QC worker instances to divide a topic's partitions among themselves automatically — the maximum useful parallelism is capped by the partition count, so the "Consumer Parallelism" control in a streaming pipeline is really choosing how many QC workers can process records concurrently. Consumer lag, defined as the difference between the latest offset written to a partition and the offset last committed by a consumer, is the primary real-time health signal for this stage: a lag that grows unboundedly means consumers cannot keep pace with the sequencer's output rate and a backlog is accumulating in the topic.
Operationally, teams monitor lag continuously and autoscale QC consumer replicas when lag crosses a threshold (commonly several thousand offsets), since Kafka's retention buffer only buys time, not unlimited slack.
A single high-output PromethION flow cell can emit well over 1,000 reads per second at peak; with too few consumer instances relative to partitions, lag can climb into the tens of thousands of offsets within minutes, delaying every downstream alignment and dashboard update by the same margin.
Filtering thresholds are not free — every additional criterion trades sensitivity for cleanliness. An aggressive minimum-quality cutoff removes more sequencing error but can systematically bias coverage against genomic regions that are intrinsically harder to sequence (high-GC content, homopolymer runs, secondary structure), since reads spanning those regions tend to have lower raw quality regardless of the underlying DNA's validity.
Many production pipelines therefore use adaptive thresholds that loosen as a run progresses and total yield is assessed against the coverage target, or that apply different cutoffs per genomic region of interest versus off-target background. The filtering stage's output is intentionally a strict subset of the input stream — every record that is dropped here is a record the aligner and dashboard will never see, which is precisely the point: compute and storage downstream scale with useful data, not raw instrument output.
Filtered reads are aligned to the reference genome the moment they arrive, using minimap2 in streaming mode, with alignments appended incrementally to a growing, coordinate-sorted BAM/CRAM file. Coverage depth and variant-calling inputs are therefore available minutes into a run rather than only after the final read has been written — a decisive advantage for time-critical applications like outbreak genomics and rapid clinical diagnosis.
minimap2 is the de facto standard aligner for both long (Nanopore) and short (Illumina) reads, built around a seed–chain–align pipeline: it first indexes the reference genome into minimizers (a reduced, sampled set of k-mers that dramatically shrinks the search space while preserving sensitivity), then for each incoming read finds seed matches against that index, chains compatible seeds into candidate alignment regions, and finally performs base-level alignment (using an SIMD-accelerated dynamic-programming extension) only within those candidate regions.
Because the reference index is built once and held in memory, minimap2 can be invoked continuously against a stream of individual reads or small read batches pulled from the post-QC Kafka topic, rather than waiting to be pointed at one large completed FASTQ file — each read's alignment record is produced independently and can be emitted the instant that read's alignment finishes, typically a few milliseconds after the read enters the aligner process.
Producing a single coordinate-sorted, indexed BAM file incrementally is nontrivial, since reads do not arrive in genomic coordinate order — they arrive in whatever order the sequencer produced them. Streaming pipelines commonly write alignments to a temporary unsorted or block-sorted BAM using htslib's streaming write APIs, then periodically (commonly every 30–60 seconds) run an incremental sort-and-merge pass and refresh the BAM index (a .bai or .csi index built via samtools index) so that genome browsers such as IGV, or coverage-computation tools, can "tail" the file and see approximately-live coverage without waiting for run completion.
Some pipelines instead write per-chunk sorted BAM segments and merge them lazily on read, trading a small query-time cost for eliminating repeated full-file sorts as the file grows across a multi-hour run.
The clinical and public-health value of incremental alignment is concrete and time-critical. In hospital-acquired infection and sepsis-pathogen identification workflows, Nanopore sequencing coupled to real-time alignment and species/resistance-gene classification has been used to return an actionable pathogen ID and antimicrobial-resistance profile within hours of sample collection, compared to 24–72 hours for culture-based methods.
During outbreak response (as demonstrated extensively during regional Ebola and SARS-CoV-2 sequencing efforts), field-deployed MinION sequencers paired with streaming alignment pipelines allowed genomic surveillance teams to identify variant lineages and transmission clusters while a sequencing run was still in progress, rather than waiting for it to finish and then batch-processing the output overnight.
Collapsing time-to-first-variant from roughly 48 hours in a traditional batch pipeline to around 4 hours end to end is not merely a convenience — in sepsis cases, where mortality risk climbs measurably with every hour of inappropriate antibiotic therapy, this reduction can directly change clinical outcomes.
A downstream Kafka consumer aggregates throughput, quality, and alignment metrics into rolling windows and pushes them to a monitoring layer — typically Prometheus for metric storage and Grafana for visualization — giving lab operators second-by-second visibility into read throughput, backlog, basecall accuracy, and per-target coverage depth, together with an estimated time to reach the desired coverage target.
Raw per-read events are far too granular to plot directly, so a stream-processing layer — commonly Kafka Streams or ksqlDB — computes windowed aggregates continuously: a sliding or tumbling window (for example, a 10-second tumbling window recomputed every second) rolls up reads-per-second, mean Q-score of reads passing QC, consumer lag per partition, and incremental coverage depth per genomic bin.
These aggregates are themselves published to a compact metrics topic, decoupling expensive per-read computation from the lightweight, high-frequency reads the dashboard layer needs to stay responsive. This windowed-aggregation pattern is what allows a dashboard to redraw every second without re-scanning the entire run's history on every refresh.
Aggregated metrics are scraped or pushed into Prometheus, a time-series database purpose-built for this kind of high-cardinality, high-frequency operational data, and rendered in Grafana dashboards as live sparklines, gauges, and heatmaps — coverage-by-genomic-bin is a natural heatmap, while reads/sec and consumer lag are natural time-series panels.
Threshold-based alert rules (evaluated continuously by Prometheus Alertmanager) catch operationally significant events automatically: a stalled coverage curve, a consumer lag spike beyond the 5,000-offset threshold used in the QC stage, or a sudden drop in mean Q-score suggesting a failing flow cell — each can page an operator or trigger an automated corrective action within seconds of the underlying condition arising.
Because the whole pipeline — basecalling, publish, QC, alignment, and aggregation — operates in well under a second of cumulative latency per read, a dashboard alert can fire within roughly ten seconds of a real degradation starting on the instrument itself, versus discovering the same problem only after a multi-hour run completes.
Real-time dashboards change what operators can do mid-run, not just what they can see. A run trending toward insufficient coverage of a clinically relevant target can be extended or supplemented before the flow cell is exhausted; a flow cell showing a collapsing pore count or falling Q-score can be aborted and reloaded rather than run to completion for a low-yield result; adaptive-sampling targets can be revised once early coverage data shows which regions are already well covered.
Each of these mid-run interventions saves reagent cost, instrument time, and — in clinical contexts — turnaround time that directly affects patient care, all of which are unavailable in a purely batch, end-of-run analysis model.
As basecalling and QC compute move increasingly onto the sequencing instrument itself (edge GPUs embedded in benchtop and even handheld sequencers), the boundary between "on-instrument" and "streaming pipeline" continues to blur, with adaptive sampling decisions, QC filtering, and even preliminary alignment happening within the same real-time loop that once only produced raw signal.
Multi-site sequencing networks are beginning to federate these live dashboards across facilities, aggregating anonymized run-health and outbreak-surveillance metrics into shared views — extending the same streaming-ingestion principles used within a single lab to coordinate genomic surveillance across an entire region or health system in near real time.