6 min read

Architecture of the Proxy Layer

architecture security proxy
Русская версия

When multiple MVPs interact with external APIs, the question arises: who controls the outgoing traffic? If each service calls external APIs directly, issues with security, auditing, and data management emerge.

Problem

Imagine you have three MVPs, each using the OpenAI API. Without centralization:

  • Each service stores its own API key
  • There is no unified call log
  • Personal data may leak in the payload
  • It is impossible to quickly disable a provider

Solution: api-broker

api-broker is a single point for outgoing calls. All MVPs access external APIs through it.

Payload Classification

Each request is classified by sensitivity level:

  • Class A — technical payload without personal data. Passes freely.
  • Class B — acceptable after filtering. Emails and names are masked before sending.
  • Class C — prohibited. Contains data that cannot be transmitted to an external API.

Masking

Before sending to the external API, the broker:

  1. Checks the payload for PII (personally identifiable information)
  2. Masks emails, phone numbers, full names, and Telegram handles
  3. Replaces user IDs with anonymous tokens
  4. Logs the fact of masking

Audit

Each call is recorded in the log:

  • Who made the call (which MVP)
  • Which provider
  • Which route
  • Response status
  • Whether masking was applied

The response payload is not stored — only metadata.

Provider Registry

Each external API is registered as a provider with the following details:

  • Country
  • Type of data it accepts
  • Risk class
  • Allowed routes

This allows for architectural decisions to be made at the policy level rather than at the code level of each MVP.

Next Steps

The proxy layer is currently in the design phase. The first implementation will appear alongside the first MVP that uses an external API.