Event-Driven ArchitectureにおけるChoreographyとOrchestration | CyberAgent Developers Blog
はじめに こんにちは、AI事業本部の伊藤(@tsutsun17)です。先日、ラスベガスで開催されたAWS re:invent 2022に現地参加してきました。 AI事業本部では例年、エンジニア数人が現地参加して熱量と学びを得ることができる環境がありました。直近2年は世の情勢もあり現地参加を控えていましたが、今年は現地参加できました。今回は、参加したセッションの中で特に面白かったセッションの一部について、考察や開発しているプロダクトのお話も含めながらご紹介したいと思います。 セッションの概要 まずは、セッションの概要についてご紹介します。 Building next-gen applications with event-driven architectures Event-driven architectures can solve many difficult problems in m
Catalog of Patterns of Distributed Systems
Distributed systems provide a particular challenge to program. They often require us to have multiple copies of data, which need to keep synchronized. Yet we cannot rely on processing nodes working reliably, and network delays can easily lead to inconsistencies. Despite this, many organizations rely on a range of core distributed software handling data storage, messaging, system management, and co
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
分散システムでのフォールバックの回避
重大な障害が発生したサービスからは、有用な結果を得ることができなくなります。たとえば、e コマースウェブサイトでは、製品情報のデータベースクエリが失敗すると、ウェブサイトは製品ページを正常に表示できません。Amazon のサービスは、信頼性を高めるために、重大な障害の大部分を処理する必要があります。重大な障害を処理するための戦略には、大きく次の 4 つのカテゴリーに分かれます。 • 再試行: すぐに、または少し遅れて、失敗したアクティビティを再度実行します。 • 積極的な再試行: アクティビティを並行して複数回実行し、最初のアクティビティを使用して終了します。 • フェイルオーバー: エンドポイントの別のコピーに対してアクティビティを再度実行するか、できればアクティビティの複数の並行コピーを実行して、それらの少なくとも 1 つが成功する確率を上げます。 • フォールバック: 異なるメカニズ
Documenting Architecture Decisions
Context Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins. Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small
EIP - Java EE勉強会
Menu Top JavaEE勉強会 参加するには FAQ MakingSenseofStreamProcessing MicroservicesVsSOA ModernJavaEEDesignPatterns BSA EIP DSL DDD 議事録 最新の20件2023-11-24 MicroservicesVsSOA/The World of Service-Based Architectures 2020-11-14 DDD/Knowledge-Rich Design MakingSenseofStreamProcessing/Example Implementing Twitter 2020-10-28 EIP/Aggregator 2019-12-18 EIP/Publish-Subscribe Channel 2018-06-10 FrontPage 2017-07-08 Ma
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
Serverless Architectures
Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverl
Handling five billion sessions a day – in real time
Since we first released Answers seven months ago, we’ve been thrilled by tremendous adoption from the mobile community. We now see about five billion sessions per day, and growing. Hundreds of millions of devices send millions of events every second to the Answers endpoint. During the time that it took you to read to here, the Answers back-end will have received and processed about 10,000,000 anal
The Onion Architecture : part 1
Programming with Palermo Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert This is part 1. part 2. part 3. part 4. My feed (rss). I’ve spoken several times about a specific type of architecture I call “Onion Architecture”. I’ve found that it leads to more maintainable applications since it emphasizes separation of concerns throughout the system.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Write-Behind Logging
Scalability, Availability & Stability Patterns
ドメイン駆動設計とオニオンアーキテクチャ