外部APIと連携する機能のデータの持ち方のイチ事例 | メルカリエンジニアリング
こんにちは。メルペイ バックエンドソフトウェアエンジニアの id:koemu です。 今日は、外部APIと連携する機能のデータの持ち方について、振込申請のシステムを事例に取り上げていきます。 基本データ・拡張データに分ける 定義 まず、データを、「基本データ」「拡張データ」に分けます。 ここで、「基本データ」とは、提供する機能において最低限必要となる情報です。振込申請ですと以下のデータとなります。 名義 口座番号 申請日 申請受理日 振込完了日 ステータス(受付完了/送金完了/送金失敗/その他) 一方、「拡張データ」とは、基本データでは網羅していない、外部APIが必要としているデータを指します。例えば、連携用のレコード別のIDや、ステータスの遷移などです。振込申請ですと次のデータになります。 ステータス(プロセッシング事業者が持つより詳細なステータス) IDのマップ(基本データと拡張データ
主要データベースの増え続けるdisk容量の対応事例
こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
