マイクロサービスにおける決済トランザクション管理 | メルカリエンジニアリング
この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
トランザクションの設計と進化
