Katkat
Back

Design Multicloud Publishing and API Gateway

IllumioSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a distributed system that reliably replicates data from a primary database to multiple cloud providers while exposing a unified, secure API gateway for external consumers.

Scenario

You are tasked with building an event-driven synchronization service and a unified API Gateway for a global platform. The system must replicate data changes (e.g., policy updates) from a primary on-premise PostgreSQL database to multiple cloud-based deployments (AWS, GCP, Azure). Simultaneously, you must expose an API gateway that allows external clients to interact with these cloud instances consistently.

Requirements

  1. Event Publishing: Changes in the primary DB must be reliably propagated to all cloud regions. Consider how to handle out-of-order events, network partitions, and potential duplicate deliveries.
  2. Consistency: Describe the strategy for ensuring cloud instances reflect the primary data state (eventual vs. strong consistency).
  3. API Gateway: Design a gateway layer that handles authentication, rate limiting, and request routing to the appropriate cloud region.
  4. Failure Handling: Explain how the system behaves if a specific cloud region becomes unreachable or if the message broker experiences downtime.

Constraints

  • The primary database must not be heavily burdened by the replication process.
  • The API gateway must support high throughput with sub-100ms latency for auth/routing.
  • Assume at least 10,000 requests per second and high availability requirements across regions.

Deliverables

  • Provide a high-level architecture diagram (described in text).
  • Detail the communication protocol between the primary DB and cloud consumers.
  • Propose a schema or metadata strategy for ensuring idempotency at the destination.
  • Define how you would monitor the "replication lag" between the primary DB and the cloud regions.

Hints

Hint 1

Consider using Change Data Capture (CDC) tools to stream database logs to a message bus like Kafka to decouple the primary database from cloud replication.

Hint 2

Use an idempotency key in your message payload or a versioning/timestamp field in your database records to ensure the cloud-side processors handle events in the correct order.

Hint 3

For the API Gateway, leverage a sidecar or a globally distributed proxy layer that caches auth tokens and implements token bucket algorithms for rate limiting.

Follow-up questions

  • How would you handle a scenario where a schema migration occurs in the primary database but the cloud regions are running an older version of the service?
  • If a cloud region is offline for two hours, what is your strategy for catching up once connectivity is restored without flooding the region?
  • How would you incorporate 'circuit breakers' into the API Gateway to prevent a degraded cloud region from impacting the overall platform availability?