最近のソフトウェアは，リアルタイムに近いデータ操作を行うことが多くなっている。 秒以下の応答でデータ交換することにビジネス価値のある状況において，従来のバッチベースの処理では対抗できない。データを可能な限り早く知識に転換する，その手段のひとつがストリーム処理だ – Kevin Webber氏はリアクティブストリーム(Reactive Streams)について，このように説明する。ストリーム処理に適したシステム例として氏が考えるのは，ETL(抽出, 変換, ロード/extract, transform, load)やCEP(複合イベント処理/complex event processing)システムといった，レポートシステムあるいは分析システムである。
Typesafeでビジネス提案を担当するWebber氏は，ストリームについて，長時間にわたって，時には始まりも終わりもなく出力される要素の連続体である，と説明する。固定サイズの数値配列であれば容易な平均値計算も，データ数が無限の場合もあるストリームでは非常に難しい作業となる。同時にこれは，ストリームの重要な側面でもある。ストリームでは，個々の要素すべてを処理することが必ずしも期待されてはいないのだ。絶えず流動し，刻々変化するデータ集合を伴う処理という観点でストリームを考える必要があることを，氏は合わせて強調する。
リアクティブストリームはシステムを構築する上で，開発者が従うべき仕様のひとつである。リアクティブシステムの目的は抽象化レベルの向上にある。低レベルのストリーム構造は，この仕様では，ライブラリ実装によって解決すべき問題として位置付けられている。
リアクティブシステム仕様の大きな目標のひとつは，システムのコンポーネント間を時間的に分割する手段として，非同期のバウンダリを設けることだ。同期処理の世界では，機能や操作は時系列的にひとつひとつ実行される。最初のものを除けば，処理の完了は１つ前のプロセスに影響を受けることになる。氏はこれをメンテナンス上の負担であり，完全にレスポンシブなシステムの構築を阻害する要因と考える。このような設計は，応答性におけるアンチパターンであり，スケーラビリティやレジエンスに悪影響を及ぼす，という見解なのだ。今日のマルチコアCPUアーキテクチャのアドバンテージを最大限に利用するには，コンポーネントの分離を促進し，同期処理的であった機能の並列化を可能にするような，従来とは完全に異なるモデルが必要だ – Webber氏はこう主張する。
もうひとつの大きな目標は，バックプレッシャ処理モデルを定義することだ。 ストリームプロセスの理想的パラダイムは，データを発行側から参照側にプッシュして，発行側は可能な限り高速に動作できることである。バックプレッシャは，高速に動作する発行側が，低速な参照側に過度な負荷を掛けないためのひとつの方法だ。バックプレッシャはフロー制御とともに機能することでレジエンスを提供し，処理の定常性と緩やかな退行を実現する。
TypesafeのシニアディレクタであるJamie Allen氏は先日公開したブログ記事の中で，皿洗いを例にあげて非同期，非ブロック型という並列処理の観点を説明し，増加するワークロードをリアクティブシステムが扱う方法と比較している。