Desain skema pembayaran berulang di DynamoDB

Kasus penggunaan bisnis pembayaran berulang

Kasus penggunaan ini membahas penggunaan DynamoDB untuk menerapkan sistem pembayaran berulang. Model data memiliki entitas berikut: akun, langganan, dan tanda terima. Spesifikasi untuk kasus penggunaan kita meliputi hal berikut:

• Setiap akun dapat memiliki beberapa langganan

• Langganan memiliki NextPaymentDate ketika pembayaran berikutnya perlu diproses dan NextReminderDate ketika pengingat email dikirim ke pelanggan

• Ada item untuk langganan yang disimpan dan diperbarui saat pembayaran diproses (ukuran item rata-rata sekitar 1 KB dan throughput-nya tergantung jumlah akun dan langganan)

• Prosesor pembayaran juga akan membuat tanda terima sebagai bagian dari proses yang disimpan dalam tabel dan diatur untuk kedaluwarsa setelah jangka waktu tertentu dengan menggunakan atribut TTL

Diagram hubungan entitas pembayaran berulang

Ini adalah diagram relasi entitas (ERD) yang akan kita gunakan untuk desain skema sistem pembayaran berulang.

Pola akses sistem pembayaran berulang

Ini adalah pola akses yang akan kita pertimbangkan untuk desain skema pembayaran berulang.

1. createSubscription

2. createReceipt

3. updateSubscription

4. getDueRemindersByDate

5. getDuePaymentsByDate

6. getSubscriptionsByAccount

7. getReceiptsByAccount

Desain skema pembayaran berulang

Nama generik PK dan SK digunakan untuk atribut kunci guna memungkinkan penyimpanan berbagai jenis entitas dalam tabel yang sama seperti entitas akun, langganan, dan tanda terima. Pertama, pengguna membuat langganan dan setuju untuk membayar sejumlah biaya pada hari yang sama setiap bulan sebagai harga atas suatu produk. Pengguna dapat memilih salah satu hari dalam sebulan untuk memproses pembayaran. Terdapat juga pengingat yang akan dikirim sebelum pembayaran diproses. Aplikasi bekerja dengan menjalankan dua tugas batch yang berjalan setiap hari: satu tugas batch mengirimkan pengingat yang jatuh tempo hari itu dan tugas batch lainnya memproses semua pembayaran yang jatuh tempo hari itu.

Langkah 1: Tangani pola akses 1 (createSubscription)

Pola akses 1 (createSubscription) awalnya digunakan untuk membuat langganan, dan detail yang mencakup SKU, NextPaymentDate, NextReminderDate, dan PaymentDetails diatur. Langkah ini menunjukkan status tabel hanya untuk satu akun dengan satu langganan. Mungkin ada beberapa langganan dalam koleksi item jadi ini adalah one-to-many hubungan.

Langkah 2: Tangani pola akses 2 (createReceipt) dan 3 (updateSubscription)

Pola akses 2 (createReceipt) digunakan untuk membuat item tanda terima. Setelah pembayaran diproses setiap bulan, pemroses pembayaran akan menulis tanda terima kembali ke tabel dasar. Di sana, bisa ada beberapa tanda terima dalam koleksi item jadi ini adalah one-to-many hubungan. Pemroses pembayaran juga akan memperbarui item langganan (Pola akses 3 (updateSubscription)) untuk memperbarui NextReminderDate atau NextPaymentDate bulan berikutnya.

Langkah 3: Tangani pola akses 4 (getDueRemindersByDate)

Aplikasi memproses pengingat untuk pembayaran dalam batch untuk hari ini. Oleh karena itu, aplikasi perlu mengakses langganan pada dimensi yang berbeda, yaitu tanggal, bukan akun. Ini adalah kasus penggunaan yang baik untuk indeks sekunder global (GSI). Pada langkah ini kita menambahkan indeksGSI-1, yang menggunakan NextReminderDate sebagai kunci GSI partisi. Kita tidak perlu mereplikasi semua item. Ini GSI adalah indeks jarang dan item tanda terima tidak direplikasi. Kita juga tidak perlu memproyeksikan semua atribut—kita hanya perlu menyertakan subset atribut. Gambar di bawah ini menunjukkan skema GSI-1 dan memberikan informasi yang diperlukan aplikasi untuk mengirim email pengingat.

Langkah 4: Tangani pola akses 5 (getDuePaymentsByDate)

Aplikasi memproses pembayaran dalam batch untuk hari ini dengan cara yang sama seperti pengingat. Kami menambahkan GSI-2 dalam langkah ini, dan menggunakan NextPaymentDate sebagai kunci GSI partisi. Kita tidak perlu mereplikasi semua item. Ini GSI adalah indeks yang jarang karena item tanda terima tidak direplikasi. Gambar di bawah ini menunjukkan skema GSI-2.

Langkah 5: Tangani pola akses 6 (getSubscriptionsByAccount) dan 7 (getReceiptsByAccount)

Aplikasi dapat mengambil semua langganan untuk akun dengan menggunakan kueri pada tabel dasar yang menargetkan pengenal akun (thePK) dan menggunakan operator rentang untuk mendapatkan semua item di mana SK dimulai dengan “#”SUB. Aplikasi ini juga dapat menggunakan struktur query yang sama untuk mengambil semua tanda terima dengan menggunakan operator rentang untuk mendapatkan semua item di mana SK dimulai dengan “REC#”. Hal ini memungkinkan kita memenuhi pola akses 6 (getSubscriptionsByAccount) dan 7 (getReceiptsByAccount). Aplikasi menggunakan pola akses tersebut sehingga pengguna dapat melihat langganan saat ini dan tanda terima lama mereka selama enam bulan terakhir. Tidak ada perubahan pada skema tabel dalam langkah ini dan kita dapat melihat di bawah ini bagaimana kita hanya menargetkan item berlangganan dalam pola akses 6 (getSubscriptionsByAccount).

Semua pola akses dan bagaimana desain skema mengatasinya dirangkum dalam tabel di bawah ini:

Pola akses	Tabel dasar//GSILSI	Operasi	Nilai kunci partisi	Nilai kunci urutan
createSubscription	Tabel dasar	PutItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
createReceipt	Tabel dasar	PutItem	ACC#account_id	REC#<RecieptDate>#SKU<SKUID>
updateSubscription	Tabel dasar	UpdateItem	ACC#account_id	SUB#<SUBID>#SKU<SKUID>
getDueRemindersByDate	GSI-1	Kueri	<NextReminderDate>
getDuePaymentsByDate	GSI-2	Kueri	<NextPaymentDate>
getSubscriptionsByAkun	Tabel dasar	Kueri	ACC#account_id	SK mulai_dengan “#” SUB
getReceiptsByAkun	Tabel dasar	Kueri	ACC#account_id	SK mulai_dengan “#” REC

Skema akhir pembayaran berulang

Berikut adalah desain skema akhir. Untuk mengunduh desain skema ini sebagai JSON file, lihat Contoh DynamoDB di. GitHub

Tabel dasar

GSI-1

GSI-2

Menggunakan No SQL Workbench dengan desain skema ini

Anda dapat mengimpor skema akhir ini ke No SQL Workbench, alat visual yang menyediakan pemodelan data, visualisasi data, dan fitur pengembangan kueri untuk DynamoDB, untuk mengeksplorasi lebih lanjut dan mengedit proyek baru Anda. Ikuti langkah-langkah berikut untuk memulai:

1. Unduh No SQL Workbench. Untuk informasi selengkapnya, lihat Unduh No SQL Workbench untuk DynamoDB.

2. Unduh file JSON skema yang tercantum di atas, yang sudah dalam format model No SQL Workbench.

3. Impor file JSON skema ke No SQL Workbench. Untuk informasi selengkapnya, lihat Mengimpor model data yang ada.

4. Setelah Anda mengimpor ke NOSQL Workbench, Anda dapat mengedit model data. Untuk informasi selengkapnya, lihat Mengedit model data yang ada.

5. Untuk memvisualisasikan model data Anda, menambahkan data sampel, atau mengimpor data sampel dari CSV file, gunakan fitur Visualizer Data dari No Workbench. SQL