良いシステム設計？面接で評価されるのは複雑さだった
引用元：https://news.ycombinator.com/item?id=44921137
良い設計はシンプルなのに、面接では複雑なシステム設計を求められるって話。
「バックプレッシャー？いらない」「キューじゃなくてCron？それで十分」「DBはどっちでもいい？」みたいな答えはダメ。面接官はホワイトボードを箱と矢印で埋め尽くすような複雑な設計を期待してるんだって。
面接官としては、シンプルな答えから始めてくれてOK。
問題解決した上で時間が余ったら、複雑な設計の話を深掘りするよ。キャッシュだけで全て解決しようとする中堅エンジニアが、どうやってキャッシュを埋めるのかって聞かれて困るのを見るのは結構楽しいね。
面接官から見ると、君の答えは説明不足だね。
なぜその選択をするのか、その背景にある思考をしっかり言葉にしてほしい。優秀な面接官は引き出すけど、そうじゃない面接官だと「情報が引き出せない」って判断されるよ。あと、SQL/NoSQLの選択について「チームの expertise」だけってのは経験不足のサインかも。技術の根本的な違いを理解しておくべきだ。
ソフトウェア業界で20年働いてるけど、「バックプレッシャー」って言葉、初めて聞いたな。
もう俺、時代遅れなのかな？
「面接は双方向」って話だけど、君の答えはすごく合理的で、俺が面接官なら即採用だよ。
もし君がそんな答えで落ちるなら、その会社は合わないだろうね。でも、すぐに仕事を見つけなきゃいけない状況もあるから、相手の期待に合わせるのも必要だってのは理解できるよ。
そんな職場で働きたい？
僕の経験だと、面接でKubernetesを使ってKubernetesを動かすような設計を求められる会社は、実際のシステムもそんな感じだよ。
シグナルの話、本当にそう思う。
優秀な候補者なら、バックプレッシャーについて聞かれたら、それがなぜ今のQPSでは不要なのか、いつ頃必要になるか、そして将来どう設計に組み込むかまで、自ら詳しく説明するはずだ。シニアになるほど、面接官に多くの「シグナル」を与えるために、自分で面接をリードする能力が重要になるんだ。
こういう（複雑な設計を求める）ところが、実際に給料がいいんだよ。
面接官の質問は、知識を見せる絶好のチャンスだよね。
バックプレッシャーについて聞かれたら、thread-per-CPU w/ async I/O の設計とか、ヘルスモニタリング、外部サーキットブレーキング、429やフローコントロールの話まで、深く掘り下げて語るよ。thread-per-client デザインの良くない点なんかも話して、面接官が「もう十分」って言うまで、こちらの知識をアピールし続けるのがコツだね。
面接官が「まずは基本的な回答で、時間があったら複雑な話に移ろう」って explicitly に伝えればいいのにね。そうじゃないと、候補者って最初からFAANGスケールの問題解決能力を見せつけなきゃって思い込んじゃうんだよ。これって期待値のズレが原因だよね。
もし俺が面接官だったら、君の答えはすごく評価するけど、rubric の項目にはチェックをつけられないんだ。デブリーフィングで説明しようとしても、バイアス回避のために rubric に従えって言われ、結局 architecture Jenga を選んだやつに合格を譲っちゃうことになるだろうな。謝りたくなるけど、責任問題になるからしないけどね。
俺は Martin Kleppmann が言うような、複雑さが正当化されるデータ集約型アプリを扱いたいんだよね。「All you need is Postgres」派なんだけど、Discord が Cassandra や ScyllaDB で 1兆メッセージを扱う記事とか見ると、やっぱり羨ましいんだよな。でも、そういうとこに雇われるには、その経験を先に証明しろって、これって catch-22 だよね。
この点について、もっと詳しく記事を書いてくれよ！有料でも読むからさ。
C10K技術について俺のコメントで書いたこと、要約するね。thread-per-client は非効率でメモリ消費も多い。CPS async I/O とか async function を使うと、プログラムの状態を小さくできるから、メモリやキャッシュのフットプリントを減らせるんだ。これこそ C10K 技術のポイントだよ。thread-per-CPU も効率的だし、サービス全体の健全性管理も楽になる。バックプレッシャーやサーキットブレーカーも大事。LLM はこの辺のこと知ってるけど、C10K 技術はジュニア開発者にはコストが高いね。
そもそも、こんな会社で働きたいなんて思わないだろ。
候補者が QPS やストレージ、スループットに関する質問をしないのはダメだね。もし分散システム設計を見たいなら、具体的なトラフィック量を伝えてから再設計させたらいい。それでも指定された負荷を捌けないシステムを設計し続けるなら、そいつは不合格でしょ。
多くの候補者がトレードオフとかニュアンスを理解せずに、バズワードやパターンだけを覚えちゃうから、こんな問題が起きるんだよ。有能な面接官なら、知識の浅さなんてすぐバレるはずなんだけどね。
儲かってる会社だけがオーバーエンジニアリングに手を出せるんだよな。儲かれば儲かるほどオーバーエンジニアリングは広まって、その維持のために大金を払うようになるんだ。
FAANG で高給をもらいたければ、この手のシステム設計面接を受けるしかないんだよ。FAANG で働かないって選択肢もあるけど、FAANG が最高額を払うのは事実だからね。
面接ではね、まず基本的な回答から始めて、時間があれば複雑な話に深掘りするんだってさ。これって、いつ、なんでその技術が必要なのかを説明できるかどうかが理解度を示すってことだよね。スタートアップだから関係ないとか、慣れてるDB使うとかいうのは知識不足。適当にやる候補者も過剰設計する候補者もどっちもダメ。面接は知識を見せる場であって、あれこれ議論する場じゃないんだよ。
こういうレベルになると、文脈から自分で解決策を見つけるスキルが超重要になるんだ。だって君は仕様をコードにする人じゃなくて、仕様を作る側の人だからね。
「Postgresがあれば十分」っていうのはさ、「メッセージが1兆個になるまでは」って暗黙の前提があるんだよね。みんな、最初からCassandraやScyllaDBを使ったわけじゃなくて、メッセージが多すぎて困ったから使い始めたんだ。それってアーキテクチャの選択っていうより、プロダクトが成功した結果だよな。
システムレベルでも理由があるんだよ。ちゃんと分離してないと、スレッド同士がぶつかり合って応答が遅くなるっていうフィードバックループが起きる。リクエストが増えると並行スレッドも増えて、さらに遅くなる悪循環。一時的なピークでも応答時間が臨界点を下回ると、システムは回復できず、サーバーがやたら計算し続けて再起動しないと治らなくなるんだ。
FAANGの高給が欲しいなら、FAANGの面接ゲームをちゃんとやらないとダメってことだろ？それが嫌ならFAANGのお金は諦めるべきだよ。
昔いた会社のCTOとVP of Engは尊敬できたなー。会社が大きかったのに、複雑さとか過剰設計を最小限に抑えてたんだ。残念ながら、今は幹部がAIでの生産性向上にめちゃくちゃ力を入れてて、めちゃくちゃになってるけどね。
俺が面接官だったら、知識の深さを探るために仮説をぶつけるね。「QPSには関係ない」って言われたら、「マイケル・ジャクソンが死んだら？」って。DDoS対策、キャッシュ、新キャパシティとか話せるか見る。cron jobとqueueの質問に「必要ない」って言われたら、「一部顧客が高速応答を要求したら？」って聞く。SQLとNoSQLの選択は、インデックス、ジョイン、スキーマ移行とか話せないと知識に穴がある。シニア候補はアーキテクチャ決めるんだから、チーム入れ替えるくらい簡単にアーキテクチャも変えられるんだよ。
バズワードを並べるだけでトレードオフを理解してない候補者を見抜くのは簡単だよ。面接はトレードオフを理解してるか聞く場なんだから。上のコメントみたいにトレードオフを議論せずに結論に飛ぶのはダメ。そういう答え方だと、賢いのか適当に言ってるだけなのか区別つかないんだよね。トレードオフに触れて質問に答えるのが一番。質問を却下しようとするのは絶対に損だよ。
問題はさ、単一システムがどれだけ処理できるかっていう認識がずれてることだよね。俺の8年前のデスクトップPCでも、数万rpsを15msのp99で処理できるんだぜ。Visaだって世界中で7万tpsくらいだって。以前、面接で「毎分数万イベントを処理するシステム設計」って聞かれて、「特別なことしなくていい、普通のPostgres/MySQLでノートPCでも余裕」って答えたんだ。そしたら採点基準にKafkaが期待されてたらしい。マジ意味わかんねぇ。
面接で相手が求める答えがわかるなら、ちょっと調整すれば通るよ。もしわからなくても、そいつらと働きたくないってわかる良い機会だと思えばいいさ。
面接でBackpressureとかDB選択について聞かれたら、知識を披露するチャンスだ。質問を避けたり、反論したりすると印象悪いよ。スタートアップで実際問題になった時、候補者が「そんなの関係ない」って言うのを聞いて、ガッカリした経験があるんだ。まずは質問にきちんと答えよう。
もっとコメントを表示（1）
記事の「複数のサービスでDB共有はダメ」ってのは一概に言えないよ。DBを直接インターフェースにすれば、設計・実装なしでTransactionとか認証がすぐ使える。自分でAPI作ると故障箇所も増えるしね。でも、複数のサービスが同じDBにアクセスしてるのは、そのDBが本来は別々のものだったってサインかもしれないね。
いや、DBをインターフェースにするなら、ちゃんと設計・実装しないとダメだよ。複数のサービスからだと制約増えるし、移行も大変だ。APIの方がクリーンで柔軟なんだけど、ビジネスの都合で手抜きしてDB直接アクセスしちゃうんだよね。DBが肥大化していくって意見には同意するよ。
PostgreSQLなら、複数のアクセスパターンとか移行のオーバーヘッド、DBレベルでのアクセス制御とか、全部対応できるよ。
PostgreSQLでできるかどうかじゃなくて、「それが良いアイデアか」が問題だよ。内部テーブルを外部に公開すると、クエリやデータモデル、技術変更で問題が出やすい。API層の方が柔軟で安定するんだ。でも、同じチーム内ならDB直接アクセスもアリだけどね。
SQLのデータ型を別の言語に移しても、移行の面倒くささはなくならないよ。アプリ側で隠せる移行はSQLでもできるし、DBだってアプリコードと同じこと表現できるんだからさ。
SQLをインターフェースにするのは良いけど、前のコメントは間違ってるね。DBのMigrationには、アプリじゃ対処できない変な制約がたくさんあるんだ（Index作成時のLockとか）。DBを直接触らせない一貫したService Layer（APIじゃなくてもOK）がないと、できない変更も多いんだよ。
前のコメントにあった「一貫したService Layer」は、Stored ProcedureとかViewを使ってDB自体に実装する手もあるよ。DBMSに強く依存したり、SQLの書きにくさはあるけど、不正なアクセスを防げるし、性能が上がることもあるんだ。
Index作成時のLockでDowntime、って話はもう解決済みだよ。MySQL/MariaDBは短いLockだし、PostgresにはCONCURRENTLYがある。データ移行ならTriggerを使えばいい。それでもダメならProxySQLとかでクエリを書き換えちゃえばいいんだ。
Triggerかcreate index concurrentlyか？みんなクライアントサイドで解決するの？PerconaはTriggerを使わないんだっけ？
APIって共有DBスキーマよりずっと進化させやすいんだよね。多くのシステムで経験したけど、複数のサービスが同じDBスキーマを使うのは、絶対間違いだと確信してるよ。2000年代初期ならまだしも、今はそんな設計するべきじゃない。
15年前にSQLテキストを受け取って行を返すSOAP Webサービスを作ったんだ。すごく使われたよ。最近、それを使った会社でSQLインジェクション攻撃を試みたやつがいて、ログで捕まえられたらしい。DBスキーマが固定されてたから、後方互換性もバッチリだったんだ。
サービス固有のビューを使えばいいんだよ。
基盤のテーブルが変わったとき、ビューだけじゃ難しいこともあるよ。データが複雑でDDL変更が頻繁だと特にね。でも、APIの更新調整の方がスキーマ変更より大変な場合も多いから、状況によっては複数サービスでDBを共有するのもアリだと思うんだ。
まったくその通り！ビューじゃスキーマ進化の全てのケースはカバーできないよ。APIバージョニングの方がデータストアの変更や外部APIの利用、サードパーティ連携なんかにずっと柔軟に対応できるんだ。ビューでやろうなんて思わないでくれ！
物事が変わるとき、変更するものを最小限にするのが目標だよね。データストアを変えるってなると、そこへの全アクセスを調整しなきゃいけないから、使ってるものが少ないほど調整が楽。うちの会社でDB更新したとき、40以上のチームがアクセスを修正するのに3年もかかったよ。
DBを使うためのコードライブラリを再利用するのも一つの手だよ。
それだとAPI層がクライアントライブラリになっちゃって、配布とかビルドが面倒になるよ。サーバーサイドでAPIを提供して、クライアントに消費してもらう方が断然楽だし、サーバーをパッチする方がライブラリを全員に配るよりずっと簡単だからね。
このスレッドの議論って、インターフェースの「顧客」が組織内の他のチームって前提で進んでるよね。外部のエンドユーザー向けにはもちろんAPIだけど、内部のサービス間の連携は、もっと複雑な答えになると思うんだ。
外部だけでなく内部顧客にとってもDB直接依存はダメだね。内部スキーマに他チームが依存すると、目標や優先順位がズレたり、パフォーマンス問題、互換性問題が起きるよ。APIで合意するのがベスト。例外もあるけどね。
「複数サービスが同じDBにアクセスするのはコードの臭い」って言うけど、サービスごとに物理DBを分けると、ほとんどの場所で信頼性がNからN^Mに落ちちゃうよ。
どの視点から見てんの？サービスが動いてても、他のサービスがダウンしてたら何もできないじゃん。それって、ただダッシュボードの指標増やすだけでしょ。これって分散モノリスの話だよ。
確かにね。残念ながら、僕がこれまで関わったマイクロサービスアーキテクチャは、複数の会社でずっと分散モノリスだったんだよね。
著者は、複数のサービスからの同時書き込みは避けるべきって言いたかったんじゃないかな。それがレースコンディションの原因になりやすいからね。
Airflow 2はDBで連携してたけど、Airflow 3はAPIに切り替わったんだよ。
「それで何が得られる？」って言うけど、アーキテクチャ図のいい箱だよ。各箱を別チームに渡せば、エンジニア同士が話さなくてもシステムが突然予期せぬ形で壊れることはないしね。
Amazonでは、誰も共有DynamoDBテーブルに書き込まないってトップから決まったんだ。チームが所有してAPIを提供するようにしたら、信頼性と開発速度が劇的に上がったってさ。
チーム境界は超重要だよ。同じチームがアクセスするサービス全部を厳しくコントロールできるなら、共有DBでも長くやっていける。でも違うチームが絡むと、密結合が問題とボトルネックになるよ。プロトタイピングとかなら別だけどね。
Amazonのトップから言われなくても、広く共有されたDynamoDBインスタンスの移行とか、DAX設定変更の苦労なんて、痛いほどわかるって。
DBへのクエリはDBでやらせて、アプリコードでJOINするな！ビュー（ストアドプロシージャも）を使えば、データが抽象化されて、SQLコードも読みやすくなるし、将来的な変更にも強いぞ。DBの機能を最大限に活用するのが効率的だね。
ORMsはそこが問題なんだよ。複雑なWebサービスを構築するなら、SSR構成でMVCビューごとに生SQLビューやクエリを書くのが一番エレガントで高性能だ。RDBMSに重い処理を任せれば、最適化も効くし、WebサーバーもSQLの結果を直接HTMLに変換できる。ORMの単一オブジェクトモデルは柔軟性がなくてダメだ。
もっとコメントを表示（2）
こんな複雑なアプリを実際に作ったことある？テスト、セキュリティ（行レベルセキュリティとか）、マイグレーション、変更管理（SOC2とか）、キャッシュオフロード（Redisとか）、マイクロサービス対応とか、考慮すべきことは山ほどあるんだぞ。初めてSupabaseを触った若い開発者が、そのアプローチで無限にスケールすると思ってるような、ちょっと現実離れした意見に聞こえるな。
俺は反対だね。モダンな高スケーラブルなアーキテクチャなら、DBじゃなくて手前のバックエンドでJOINする方がいい。バックエンドはDBよりずっとスケールしやすいんだ。DBの負荷を下げて高速に保てる。もしデータがデカすぎてDBでJOINが必要って思うなら、バックエンドで扱えるように構造を見直せよ。ついでにJOINをフロントエンドに持っていけば、キャッシュ効率が上がって最高だぞ。
なんでこれらの問題が、生のSQLよりORMの方が簡単に処理できるって言うのか、俺には理解できないな。
それは粒度のトレードオフだね。SQLだとフィールドレベルで細かくテストが必要だけど、DTO的なオブジェクトモデルにマッピングすれば、もっと大きなビルディングブロックで扱えるから、シンプルで信頼性の高いアプリになる。もちろん良いORMを選ぶ必要はあるけど。うちの複雑なアプリでは、GraphQLスキーマを自由に使ってて、ORMがJOINに変換してくれるからN+1問題もなくて、リクエストも高速だよ。
俺の製造データはインスタンスあたり数百GBから数TBもある、常にアクセスされるホットデータなんだ。再構築なんて無理だし、フロントエンドでJOINなんて最悪だ。すべてのアプリが小さいわけじゃないんだよ。
場合によってはその通りだ。だけど、あなたの考え方はちょっと限定的だよ。そんなデータでも、JOINがDBでなくてもいいように整理できるはずだ。この手の設計はいつもフロントエンドから「始まる」んだ—例えばテーブルビューでどんなデータを見せるかを選ぶところからね。常に全部のデータを表示するのが唯一の方法じゃないってことを理解してない人が多いな。
本当にそう確信してるか？ウェブショップの例で考えてみてくれ。注文（5フィールド）と顧客（20フィールド）のテーブルがあって、顧客1万件、注文100万件だとする。フルJOINすると2500万フィールドも送る羽目になるけど、2つのクエリを分けてクライアント側でJOINすれば、注文で500万、顧客で20万フィールドで済むんだぞ。データ転送量に大きな差が出るんだ。
SQLデータベースには、レシピやメンテナンス、在庫とか、製造プロセスのいろんな側面を扱うアプリが10個以上もあるんだ。データは密接に連携してるけど、使う人が違うからアプリは独立してる。これは決してフロントエンドから始まるんじゃなくて、システムとして始まって、データやアプリが増えて進化してきたんだ。SAPみたいな大規模システムを想像してくれ。
古臭いデザインだよ。今はデータベースでアプリ連携なんてしないし、各アプリが自分のデータを持つサービス指向アーキテクチャの方がずっと良いね。そうすれば問題も簡単に避けられるよ。
古臭いどころか堅実な設計だよ。フロントエンドやサービスが全体を主導する設計は、一見良くても長期的に見たらダメ。データベース構造のようなデータ構造を安定させるのが、長期的なメンテには超重要なんだよ。
それって単にサボってるだけじゃない？ORMがデータマッピングを正しくやってくれるって思い込んで、確認しないってこと？
‘大規模’って言い方は主観的すぎるね。ほとんどの会社は、PostgresやMySQLの単一インスタンスで十分対応できる規模だから、そこまで心配する必要ないと思うな。
‘一見うまく見えても、長期的には悪いデザイン’は単なる意見でしょ。その設計の何がダメなの？それに、バックエンドサービスごとにDBを分けるのは、フロントエンドじゃなくデータ移行とかアクセス要件で決まるんじゃないの？
設計ルールは基本として良いけど、破るべき時を知るのが大事だよ。たくさんのテーブルをJOINすると結果が膨大になるアプリがあったんだけど、クエリを分割したらめちゃくちゃ速くなってコードもシンプルになったんだ。
後で全部JSONBにまとめちゃったら、もっと良くなったよ。
ストアドプロシージャって良さそうだけど、T-SQLでしか書けないのが最悪なんだよ。RustやC#と違って、T-SQLは昔からダメな言語だし、ツールもバージョン管理なんて信じてない。保守も診断も地獄だよ。新人のコードより読みにくいんだから。
データベースに頼りすぎるのも気をつけないとね。アプリがデータを入れたのに、DBに保存されたら全然違う値になってた、なんてことにもなるからさ。
ほとんどのORMはストアドプロシージャやビューをクラスにマッピングできるから、好きなだけモデルを持てるよ。あなたの話は的外れ。著者はORMに触れてないのに、ORMへの個人的な不満を言ってるように見える。ORMでCRUDの定型コードを減らし、それ以外は生のSQLを使うのは現実的な設計判断だ。ORMはボイラープレートを減らすし、シニア開発者なら上手に使えるはずだよ。大きなORMクエリはコードの匂い、生のSQLを使うべきサインだね。
バックエンドごとのDBはフロントエンドじゃなくて、データ移行やアクセス要件で決まるんだ。共有エンタープライズDBを分割する考えは、チームの依存関係を減らして変更しやすくするためだけど、デメリットも大きいぞ。特にSKUみたいなビジネスで共有される重要なデータが更新された時、分散モデルだとその状態を全エリアで共有するのにめちゃくちゃ複雑な作業とタイミングの問題が発生するんだ。何でもかんでも一つの解決策がベストなわけじゃない。メリットがデメリットを上回る時だけ分割すべきで、それはあんまりないんだよね。
俺がJavaプロジェクトで使ったJOOQはORMなしでSQLを安全に書けて、複雑なエンタープライズアプリでも全く問題なかったぜ。SQL移行？これは解決済みだろ。
https://github.com/flyway/flyway
マイクロサービスならTerraformでAWS Auroraとかをプロビジョニングできるし、ORMと何の関係があるんだ？RedisのキャッシュにキーがあるかチェックするのにORMが必要？そんな難しいコードじゃないだろ？あんたのコメント、「俺のやり方以外はダメで、お前はオモチャのプロジェクトで遊んでんだろ」って感じで混乱するわ。
ORMを使えば、アプリケーションコードがビューになるんだよ。再利用可能な関数を抽象化として書けて、QuerySetを返せる。実際のSQLがDBに送られる前に、さらにフィルタをチェーンできるんだ。結果は定義した元のオブジェクトモデルと一致する必要はなくて、group byで辞書形式にするとか、柔軟に対応できるんだぜ。
この記事に足りないのは、ビジネスロジックをどう分離するかだと思うな。優れたソフトウェア設計では、全てのビジネスロジックを独自の層に分離するべきだ。プロジェクト、モジュール、ネームスペースとか、言語によるけどね。ビジネスロジックはSQLやウェブサーバーのコード（コントローラ、ウェブヘルパー、ミドルウェアとか）から切り離すべき。SQLはデータストアとして扱えよ。SQLにアプリのロジックを埋め込むと、開発者が予想しない場所に核機能が隠れて、アプリとDBが密結合になって、変更や成長が難しくなるぞ。
ORMが1行ずつDBにアクセスしてるなら、使い方が間違ってるぜ。N+1クエリはパフォーマンスキラーだぞ。最近のAPMなら簡単に見つけられる。Railsだとfind_eachを使えば（デフォルトで1,000レコードずつ）クエリをバッチ処理するから簡単に避けられるんだ。このコメント欄を読んでると、未熟なORMを使ってるか、ORMの経験が浅いか、あるいはその両方かの人が多いみたいだね。
GraphQLの問題は、最適化されていないJOINになりがちだね。GraphQL APIが一般公開されている場合、非効率なクエリの発行をどう管理する？これに対処するには、JOINじゃなくてデータローダー（コード内でマージされるバッチクエリ）とかクエリのホワイトリスト化がよく使われるのを見てきたよ。
MySQLでストアドプロシージャを使おうとしたのは一度だけだけど、デバッグがほぼ不可能で超苦痛だったぜ。普通の開発者でもDBを賢く使うのは難しいのに、ストアドプロシージャはさらに問題を増やすだろうね。ストアドプロシージャはもう一つのリスクがある。コードと同期させ続ける必要があって、リリースがエラーを起こしやすくなる。だから、バージョン管理のために複雑なレイヤーを追加しないといけない。パフォーマンスや効率が極端に上がるメリットはわかるけど、それが正当化されるには本当に大きくないと割に合わないと思うな。
俺は反対だね。「分割された」データベースがもたらす問題はわかってるけど、これは何十年も前から設計されてきたやり方だ。でも、この設計はもうやめようぜ。分割された設計は現代のユースケースにはるかに適してる。みんな色んなデータを欲しがるし、頻繁にデータを変更したがるんだ。「1つの」データベースじゃ、多くのアプリで使われるからスキーマを変更できないし、うまくいかない。だから、昔の要件から来る設計に固執しちゃうんだ。もちろん、修正はできるけど、多くも根本的にも無理。分割された設計なら、DBを共有しないから何でもできる。スキーマも好きなように変更できる。データも複数形式で（重複させて）保存して、高速にクエリできる。維持すべきは外部（部門など）へのインターフェースだけ。ここではAPIのバージョン管理が使える。便利だよ。90年代は終わったんだ。当時の人々の制約にこだわる必要はない。もちろん、データがすべてのシステムで最新じゃないのは問題になることもある。でも、今のビジネスの人々は、データの構造を変えられないこと（「新しいフィールドを追加できない」、「このフィールドを変更できない」など）よりは、そっちを受け入れる傾向にあるね。
