Mewayz の 208 モジュール プラットフォームが高速かつ柔軟で壊れない仕組みを維持する方法

エンジン ルーム: 大規模な建築においてなぜ重要なのか

単一のビジネス アプリケーションを構築するのは困難です。 CRM や請求書発行からフリート管理や分析に至るまで、208 の異なるモジュールを備えた一貫したプラットフォームを構築することは、これまでとは異なる規模のエンジニアリング上の課題です。 Mewayz では、技術アーキテクチャは単なる実装の詳細ではありません。それは製品の中核となる約束です。これにより、無料枠のスタートアップ企業は CRM と並行して給与計算を実行でき、従業員 5,000 人の企業はパフォーマンスを低下させることなく、プラットフォーム全体にホワイトラベルを付けることができます。 138,000 人を超える世界中のユーザーにとって、アーキテクチャは目に見えませんが、その影響はプラットフォームの速度、信頼性、および完全な柔軟性として日々感じられます。これは、それを可能にする原理とテクノロジーの内部を見ていきます。

中心となる哲学: マイクロサービスと限定されたコンテキスト

私たちの基本的な決定は、モノリシックなコードベースを何としても避けることでした。単一の無秩序に広がるアプリケーションで人事、会計、プロジェクト管理を管理しようとすると、維持、更新、拡張するのは悪夢のような作業になります。代わりに、厳密なマイクロサービス アーキテクチャに基づいて Mewayz を構築しました。当社の 208 のモジュールはそれぞれ、独立した自己完結型のサービスです。請求モジュールには独自のデータベース、ロジック、コードがあります。フリート管理モジュールは完全に独立しています。データベースを共有したり、互いの内部関数を直接呼び出したりすることはありません。

「境界付きコンテキスト」の定義として知られるこのアプローチは非常に重要です。これは、当社の開発チームが Payroll モジュールに依存したりリスクを負ったりすることなく、Booking モジュールに取り組み、アップデートをリリースできることを意味します。そうすることで、私たちは迅速にイノベーションを起こすことができるのです。もちろん、トレードオフはこれらのサービス間の通信の複雑さですが、これは次のコア コンポーネントで解決します。

神経系: イベント駆動型コミュニケーション

マイクロサービスがプラットフォームの器官であるとすれば、イベント駆動型のコミュニケーションは中枢神経系です。サービスが相互に直接 API 呼び出しを行う (密結合が生じ、連鎖的な障害が発生する可能性がある) のではなく、サービスはイベントを発行してリッスンすることによって通信します。たとえば、販売取引が CRM モジュールで「成約済み」とマークされている場合、請求モジュールは直接呼び出されません。代わりに、イベント deal.closed.won を発行します。そのイベントをサブスクライブしている請求サービスは、そのイベントを自動的に取得し、新しい請求書草案を作成します。 CRM は、請求サービスが稼働しているか、停止しているか、または低速であるかを認識する必要はありません。

このアーキテクチャは、優れた復元力と拡張性を提供します。請求サービスが一時的に利用できない場合、イベントはオンラインに戻るまでキュー内に待機します。また、強力な分離されたワークフローも可能になります。 HR モジュールは、CRM が人事プロセスの知識を必要とせずに、deal.closed.won をリッスンして営業担当者の手数料計算をトリガーすることもできます。これらのイベントの耐久性と順序どおりの配信を保証するために、堅牢なメッセージ ブローカー (Apache Kafka) を使用しています。

データ主権と API ゲートウェイ

データが何百ものマイクロサービス データベースに分散している場合、統合された安全なデータ ビューをエンド ユーザーにどのように提供できるでしょうか?これは API ゲートウェイの仕事です。これは、Web ブラウザー、モバイル アプリ、またはパブリック API を介したサードパーティ統合からのいずれであっても、すべてのクライアント リクエストに対する単一の安全なエントリ ポイントとして機能します。ゲートウェイは、認証、レート制限、およびリクエストのルーティングを処理します。

最新のプロジェクト (プロジェクト モジュール)、未処理の請求書 (請求モジュール)、およびサポート チケット (CRM モジュール) を示すクライアント ダッシュボードを表示すると、API ゲートウェイがオーケストレーターになります。単一のリクエストを受け取り、関連するマイクロサービスにファンアウトし、レスポンスを集約して、まとまった JSON オブジェクトをクライアントに返します。このパターンにより、ユーザーが期待する統一されたエクスペリエンスを提供しながら、データがその限定されたコンテキスト内に留まることが保証されます。

結びつける接着剤: 当社のパブリック API とホワイトラベル戦略

モジュールあたり 4.99 ドルの API は思いつきではありません。それは同じ内部のエネルギーを動力源とする一級市民だ

Frequently Asked Questions

What is the biggest advantage of a microservices architecture for a business platform?

The biggest advantage is independent scalability and development. Teams can update, deploy, and scale individual modules like CRM or Payroll without affecting the stability or performance of the rest of the platform.

How does Mewayz prevent data leaks between different companies using the platform?

We use a strict multi-tenant design where every row in our databases is scoped with a `tenant_id`. This ensures that a query for one company's data can never accidentally access another's, providing a fundamental layer of security.

If a module goes down, does it take the whole platform with it?

No. Because modules are isolated microservices, the failure of one (e.g., the Booking module) does not cascade. Other modules remain fully operational, and the failed module's functions can often be queued until it recovers.

How does the white-label feature work technically?

White-labeling is possible because our presentation layer (the UI) is completely separate from our backend microservices. Partners can rebrand the front-end client, which communicates with our unified API, without touching the core business logic.

Is the public API the same as what the Mewayz web app uses?

Yes. Our public API and web app both connect through the same API Gateway to the same backend microservices. This ensures consistency, reliability, and that new features are available via the API immediately.