話そうとしない2つのシステム。話させ、話し続けさせます。

障害時の振る舞い

何かがうまくいかないとき、システムは何をするか

連携は日曜の午前2時に壊れます。503、形の変わったペイロード、重複した配信。ここが、私たちが最初に設計する部分です。

バックオフ付きリトライ

タイムアウト、429、5xxは、ジッター付きの指数スケジュールと上限付きの試行回数でリトライされます。苦しんでいる相手システムを、私たち自身のトラフィックで叩き続けることはありません。

冪等性

書き込みは安定したビジネス識別子、または相手が対応していれば冪等キーをキーにします。メッセージを2回リプレイしても、レコードはひとつ。それが、リトライとリプレイを安全にするものです。

デッドレターキュー

リトライ後も失敗するメッセージは、元のペイロード、エラー、相関IDとともに退避されます。黙って捨てられるものはなく、修正済みのバッチをリプレイできます。

人に届くアラート

失敗した実行、しきい値を超えたデッドレター、まったく動かなかったジョブは、チームがすでに見ているチャネルに通知されます。ハートビートの欠落も失敗として扱います。

ロールバックと切り替えの安全性

デプロイはバージョン管理され、元に戻せます。機能スイッチでリリースなしにフローを一時停止し、修正を準備する間は以前の振る舞いに戻します。

監査可能性

各レコードはログを通して相関IDを持ち運ぶので、「この値はどこから、いつ来たか」は調査ではなくクエリになります。

開いて確かめられる事例

何も壊さずに停止された連携。

私たちの仕事の大半は守秘義務契約の下にあります。これはそうではなく、オンラインで見られます。

対象： Automobili Zupi の公開カタログは、イタリアのディーラーがSubito.itに掲載を出すために使うバックオフィス、Multigestionale Motoriと毎時同期していました。更新されるのは変更のあった車両だけ、在庫リストから消えた車は削除ではなくアーカイブ、画像はローカルに取り込みつつ、ショールームで手作業でアップロードされたものを決して上書きしませんでした。

プロバイダーがAPIアクセスを制限したとき、同期はコマンドひとつで止められました。カタログは表示されたまま、手入力のデータは無傷、失われたレコードはゼロ。障害時の振る舞いを最初に設計する理由がこれです。止められることもそのケースのひとつで、それは必ず来ます。

よくいただく質問

送信する前に

どのシステムを連携できますか？

API、Webhook、読み取りを許可されたデータベース、またはスケジュールされたファイル交換があるものなら何でも。Bullhorn、Salesforce、ServiceNow、UKG、そして社内・カスタムシステム。必要なことに対して使えるインターフェースが製品にない場合は、その周りに壊れやすいものを作る代わりに、ディスカバリーの段階でそう申し上げます。

それらのプラットフォームの公式パートナーやリセラーですか？

いいえ。私たちは独立したエンジニアリングチームで、貴社がすでにライセンスを持つエディションの公開APIに対して、貴社の管理者が発行し取り消せる認証情報で構築します。パートナー限定の機能やアドオンは、貴社とベンダーの間の判断のままです。

稼働後、連携は誰のものですか？

あなたのものです。コード、リポジトリ、インフラ定義、ランブック。私たちが運用を続けることも、ウォークスルー付きで引き渡すことも、その両方を順に行うこともできます。私たちだけがアクセスできるアカウントの裏に閉じ込められるものはありません。

ベンダーがAPIを変更したらどうなりますか？

コントラクトは境界で検証されるので、変更または欠落したフィールドは、下流に不正なデータを書き込む代わりに、既知の場所で大きな音を立てて失敗します。バージョン固定、サンドボックスのステージング環境、スキーマとエラー率の変化に対するアラートは、追加販売ではなく構築の一部です。

誰も文書化しなかったシステムでも対応できますか？

それが仕事の大半です。スプレッドシートや手作業のステップも含めて今日実際に動いているものを整理し、コードを書く前に、その仕事をしている人と私たちの読みを検証します。