ScalaまたはClojure関数型プログラミングのベストプラクティス
私はたくさんの自習用のコーディングを行い、並列プログラミングモデル（アクター、ソフトウェアトランザクションメモリ、データフロー）のいくつかの経験を得ました。
これらのアーキテクチャを高負荷のWebアプリケーションに実際に適用しようとすると、どのモデルもデータの耐久性と永続性をサポートしません。実際のタスクでは、最後にデータを保存する必要があります。つまり、引き続きDBとトラッピングDB同期、スケーラビリティのボトルネックなどを使用する必要があります。
AkkaActors or Software Transaction Memoryを使用するアーキテクチャ（src、テキスト、図、または青写真）の良い例を知っている人はいますか？最後に永続性を実装しますか？
実際のアプリケーションでのトランザクションメモリ、アクター、データフロー、タプルスペースの良い例/アイデアを歓迎します。
アクター/ STMモデルとデータベースの永続性はある程度直交しています。一方を他方なしで簡単に持つことができ、2つを混同する危険性があると思います。
耐久性（ACIDのD）を達成することは、トランザクションの設定、特にメッセージパッシングによって調整されるアクター/プロセスがある分散設定では非常に複雑です。 ビザンチン将軍問題 のような厄介な問題に遭遇します。
その結果、特定の永続化要件を満たすために、常にある程度のソリューションの調整が必要になると思います。 「1つのサイズですべてに対応できる」ソリューションはありません。
見る価値がある（Clojureの視点）：
データ操作を実行するアクターへのメッセージは「コマンド」の同等物として使用できるため、アクターモデルは Command/Query Responsibility Segregation（CQRS） で適切に機能します。
それで、それはあなたの持続性の問題と何が関係していますか？さて、あなたはメモリに取り組み、すべてのコマンドをログに書き込みます。これは追加専用であるため、より安価な操作であり、スナップショットを時々ダンプして、必要に応じてデータベースのリロードに必要な時間を短縮します（さらに、ログが使用したスペースを回復します）。
これはかなり一般的な手法です。 VoltDBとRedisを参考にしてください。
Rich Hickeyには、Datomicと呼ばれるまったく新しい発想があります。これは、永続性、ストレージの分離、トランザクション管理、およびクエリへの新しいアプローチです。これは不変のレコードに基づいており、Datalog（Prologと機能を共有）と呼ばれるクエリ言語を使用します。主な目標は、配布とクラウド展開を容易にすることでした。サービスとしてのストレージに依存します（そのため、1つの具体的な実装ではなく、有線APIを介して疎結合されます）。
Clojureには、ACIを提供するSTMがあり、Dがありません。 DatomicはDを追加します。