質問編集履歴
9
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
|
|
7
7
|
##### 追記(2019/10/25)
|
|
8
8
|
|
|
9
|
-
※法令遵守できるかどうかといった部分で、食い違いが起きて
|
|
9
|
+
※法令遵守できるかどうかといった部分で、食い違いが起きてしまいましたので、より具体的なケースを記しました。
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
8
修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
お金のようなデータを扱うシステムはどのよう
|
|
1
|
+
お金のようなデータを扱うシステムはどのようなアーキテクチャしたら良いでしょうか
|
test
CHANGED
|
@@ -46,7 +46,7 @@
|
|
|
46
46
|
|
|
47
47
|
|
|
48
48
|
|
|
49
|
-
上のシステムを作るとなった場合、どのように
|
|
49
|
+
上のシステムを作るとなった場合、どのようなアーキテクチャにしたら良いでしょうか。
|
|
50
50
|
|
|
51
51
|
|
|
52
52
|
|
|
@@ -80,13 +80,13 @@
|
|
|
80
80
|
|
|
81
81
|
|
|
82
82
|
|
|
83
|
-
### 考えたことが全部合っている場合の
|
|
83
|
+
### 考えたことが全部合っている場合のアーキテクチャ
|
|
84
84
|
|
|
85
85
|
|
|
86
86
|
|
|
87
87
|
もし、上記の想定が合っているなら、
|
|
88
88
|
|
|
89
|
-
アプリケーションの
|
|
89
|
+
アプリケーションのアーキテクチャとして
|
|
90
90
|
|
|
91
91
|
- トランザクションログとしてkafkaのようなMQ
|
|
92
92
|
|
|
@@ -112,6 +112,6 @@
|
|
|
112
112
|
|
|
113
113
|
|
|
114
114
|
|
|
115
|
-
※法律で、資金力の問題や、免許を取得しなければならないといったシステムと直接関係のない問題は全て解決できるものとします。システム
|
|
115
|
+
※法律で、資金力の問題や、免許を取得しなければならないといったシステムと直接関係のない問題は全て解決できるものとします。システムアーキテクチャに関係のある法令(ログは3ヵ月は保持しましょうというような)を満たさない可能性をご存知であれば、ご指摘いただきたいです。
|
|
116
116
|
|
|
117
117
|
※セキュリティとして、ユーザーや管理者の認証や認可は全て正しく行われているものとします。お金固有のこだわらなくてはならないポイントがあれば、教えていただきたいです
|
7
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -6,7 +6,9 @@
|
|
|
6
6
|
|
|
7
7
|
##### 追記(2019/10/25)
|
|
8
8
|
|
|
9
|
-
※
|
|
9
|
+
※法令遵守できるかどうかといった部分で、食い違いが起きておりますので、より具体的なケースを記しました。
|
|
10
|
+
|
|
11
|
+
|
|
10
12
|
|
|
11
13
|
想定しているシステムについて追記します。
|
|
12
14
|
|
6
本文修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -3,6 +3,50 @@
|
|
|
3
3
|
会員のユーザー同士でお金のようなデータ(円やドル、仮想通貨、ポイントなど全てを含み、かつ法令を遵守できる、またユーザーにとって希少なもの)を交換するシステム(「送金」と表現することにします)をどのように作れば良いかわかりません。
|
|
4
4
|
|
|
5
5
|
ここで、想定しているのは、あるユーザーが別のユーザーに残高の一部を移動させるだけのシステムです。
|
|
6
|
+
|
|
7
|
+
##### 追記(2019/10/25)
|
|
8
|
+
|
|
9
|
+
※やはり法令遵守できるかどうかといった部分で、
|
|
10
|
+
|
|
11
|
+
想定しているシステムについて追記します。
|
|
12
|
+
|
|
13
|
+
お金について、ユーザーが何らかの決済手段を用いて得た(購入したとは限りません)、サイト内のみ使えるポイントと定めます。
|
|
14
|
+
|
|
15
|
+
ここで、ポイントとは、あくまでサイトの所有物として、万が一紛失しても責任は問われないようなケースで、ユーザーにはそのことをよく理解しているものとします。
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
あるt時点のポイントのアカウントテーブルを次のように定めます。
|
|
20
|
+
|
|
21
|
+
|id|account|user_id|
|
|
22
|
+
|
|
23
|
+
|---|---|---|
|
|
24
|
+
|
|
25
|
+
|1|100|a|
|
|
26
|
+
|
|
27
|
+
|2|70|b|
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
上記のテーブルのt+1時点は、以下です。
|
|
32
|
+
|
|
33
|
+
|id|account|user_id|
|
|
34
|
+
|
|
35
|
+
|---|---|---|
|
|
36
|
+
|
|
37
|
+
|1|90|a|
|
|
38
|
+
|
|
39
|
+
|2|80|b|
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
id:1, user_id:aのアカウントから10引いて、id:2, user_id:bのアカウントに10足した状態を表現したということです。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
上のシステムを作るとなった場合、どのように設計したら良いでしょうか。
|
|
48
|
+
|
|
49
|
+
|
|
6
50
|
|
|
7
51
|
|
|
8
52
|
|
5
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
### 分からないこと
|
|
2
2
|
|
|
3
|
-
会員のユーザー同士でお金を
|
|
3
|
+
会員のユーザー同士でお金のようなデータ(円やドル、仮想通貨、ポイントなど全てを含み、かつ法令を遵守できる、またユーザーにとって希少なもの)を交換するシステム(「送金」と表現することにします)をどのように作れば良いかわかりません。
|
|
4
4
|
|
|
5
5
|
ここで、想定しているのは、あるユーザーが別のユーザーに残高の一部を移動させるだけのシステムです。
|
|
6
6
|
|
4
タイトルを修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
お金を扱うシステムはどのように設計したら良いでしょうか
|
|
1
|
+
お金のようなデータを扱うシステムはどのように設計したら良いでしょうか
|
test
CHANGED
|
File without changes
|
3
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
4. トランザクションの原子性、一貫性、独立性を満たす必要
|
|
22
22
|
|
|
23
|
-
5. 4が満たされない(あってはならないバグが原因で)、または不正が行われた場合にある時点からリトライ・ある時点まで
|
|
23
|
+
5. 4が満たされない(あってはならないバグが原因で)、または不正が行われた場合に、ある時点からリトライ・ある時点までロールバックできるようにすること
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
2
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
4. トランザクションの原子性、一貫性、独立性を満たす必要
|
|
22
22
|
|
|
23
|
-
5. 4が満たされない(あってはならないバグが原因で)、または不正が行われた場合に強制的にロールバックできるようにすること
|
|
23
|
+
5. 4が満たされない(あってはならないバグが原因で)、または不正が行われた場合にある時点からリトライ・ある時点まで強制的にロールバックできるようにすること
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
|
@@ -40,7 +40,15 @@
|
|
|
40
40
|
|
|
41
41
|
もし、上記の想定が合っているなら、
|
|
42
42
|
|
|
43
|
+
アプリケーションの設計として
|
|
44
|
+
|
|
45
|
+
- トランザクションログとしてkafkaのようなMQ
|
|
46
|
+
|
|
43
|
-
|
|
47
|
+
- at least onceなConsumerとして残高を冪等にRDBMSのデータベースへ記録するアプリケーション
|
|
48
|
+
|
|
49
|
+
- ある時点までのトランザクションを入力とした強制ロールバック用のアプリケーション
|
|
50
|
+
|
|
51
|
+
|
|
44
52
|
|
|
45
53
|
またデータについては
|
|
46
54
|
|
1
補足を追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -55,3 +55,9 @@
|
|
|
55
55
|
|
|
56
56
|
|
|
57
57
|
以上、金融システム実装のご経験のある方からお話を伺いたいです。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
※法律で、資金力の問題や、免許を取得しなければならないといったシステムと直接関係のない問題は全て解決できるものとします。システム設計に関係のある法令(ログは3ヵ月は保持しましょうというような)を満たさない可能性をご存知であれば、ご指摘いただきたいです。
|
|
62
|
+
|
|
63
|
+
※セキュリティとして、ユーザーや管理者の認証や認可は全て正しく行われているものとします。お金固有のこだわらなくてはならないポイントがあれば、教えていただきたいです
|