QCon New York 2016で，EtsyのソフトウェアエンジニアのStefanie Schirmer氏は，自身の会社がAPIファーストアーキテクチャへの移行に成功して複数デバイスのサポートとサーバのパフォーマンス問題への対処を達成したことと，それが開発チームによって迅速に採用されたことをテーマに講演を行なった。
Etsyのエンジニアリングチームは変化に対して最適化されて，継続的な試験に積極的に取り組むそのアーキテクチャを高く評価されており，その成果として1日50回のデプロイを実現している。そのようなチームが数年前，重大なパフォーマンス問題の解決に成功していたとしても，さして意外なことではない。
1000msという目標達成を掲げたエンジニアリングチームには，クライアント要求毎のサーバ処理時間を短縮する必要があった。しかし残念なことに，シングルスレッドのPHPで並列的なAPIコールを実現するのは難しく，遅く順次的に実行せざるを得なかった。恒久的なパフォーマンス問題を回避するために，Schimer氏とその同僚は，同時実行を実現する方法を見出さなければならなかった。さらに，パフォーマンス低下の根本的理由がバックエンドの問題なのか，あるいはクライアント要求の性質によるものなのか不明確であったことが，問題をさらに複雑にしていた。
不運なことに，開発チームが取り組むべき問題はパフォーマンス向上だけではなかった。Etsy.com Webサイトのサポートやアップグレード，モバイルアプリ用の新機能も，プラットフォームに対してさらなる拡張を求めていた。２つの問題を解決するためAPIチームには，開発チームが使い慣れたAPIへのアクセス性を維持しつつ，新たな設計思想を導入する必要があったのだ。
氏らは，フラットなエンドポイントを持った単一APIを廃止して，メタエンドポイントを使用した２層APIを新たに開発した。NetflixやeBayのql.ioで使われているパターンと同じように，Etsyのメタエンドポイントはいくつかのエンドポイントを集約する。これによってサーバ側の低レベルで汎用的なリソースを，デバイスないしビュー固有のリソースに構成することが可能になった。
スタックは全体として，下のSchimer氏のスライドに示すようなマルチレベルツリーを構成している。ユーザ向けのカスタムホームページは特定のビューに合わせて調整されており，コンカレントなメタエンドポイント層を通じて各コンポーネントのエンドポイントを呼び出す。データベースにアクセス可能なのは，メタエンドポイントではない低レベルのコンポーネントのみに限られる。
メタエンドポイント層を導入したことで，Webサイトとモバイルアプリのいずれに対しても，カスタムビューを構成するための複雑さを低減することができた。しかしながら，複数のメタエンドポイントをシングルスレッドで処理していたのでは，パフォーマンス要件を満足することはできない。Etsyのエンジニアは，cURLを活用して並列的なHTTPコールを可能にするだけでなく，自分たちのニーズを満たすためにlibcurlにも手を入れた。さらに独自の監視ツールを開発し，フレームワークを通じたリクエストの呼び出し階層を視覚化することで，問題部分の特定を可能にした。
新たなAPIの採用をスムーズにする社内用ツールも開発した。また，各エンドポイントの正確なパラメータをもとに自動生成されたAPIクライアントを事前に用意することで，ドキュメントとも合わせて開発者の学習曲線の簡素化を実現した。トレーニングにはフリーサイズな単一のアプローチではなく，パイロットグループへの参加，コードラボ，ランチ付きの学習ワークショップ，経験豊富な開発者とのペアリングといった手法を活用した。
Schimer氏は自身の経験談がアーキテクチャ変更のケーススタディであり，他のシステムにも転用が可能だと考えている。APIに関連した補助ツールやサービスに注力したことは，プラットフォームチームが新たなAPIを開発者に売り込む上で有用だった。今後もShirmer氏のチームは，すべての人たちの利益のためにフレームワークを向上し続けるべく，引き続き開発者チームと意見を交換している。