Backend Decision Engine & Connector Architecture (REST, Containerised)

I am building a backend service that acts as a decision layer between an internal platform and multiple external service providers.

This is not a simple integration bridge.
The goal is to design a scalable, extensible decision engine that:
• Normalises heterogeneous API responses into a canonical internal schema
• Applies configurable business rules to determine optimal outcomes
• Abstracts external providers behind adapter contracts
• Allows new providers to be added without modifying core logic

The first external provider integration will serve as a reference implementation. However, the architecture must support rapid onboarding of additional providers via a pluggable adapter model.

⸻

Core Requirements

1️⃣ Canonical Data Model

Design a clean internal schema that:
• Normalises varying provider response structures
• Decouples core decision logic from provider-specific formats
• Supports future expansion without breaking compatibility

⸻

2️⃣ Provider Adapter Pattern
• Each external integration must be isolated behind an adapter layer
• Adding a new provider should not require modifying core engine logic
• Clear interface contracts are required

⸻

3️⃣ Decision Rule Engine

Build a configurable rule layer capable of:
• Ranking and filtering provider responses
• Applying commercial overlays or priority logic
• Supporting conditional overrides
• Avoiding hardcoded business logic

Rules must be configurable (file-based or DB-driven) rather than embedded in source code.

⸻

4️⃣ API Layer
• REST-based
• Stateless
• Container-friendly (Docker required)
• Expose clean OpenAPI/Swagger documentation
• Designed for synchronous request/response flows

⸻

5️⃣ Resilience & Observability
• Idempotent request handling
• Graceful degradation if one provider fails
• Structured logging for audit and debugging
• Rate-limit awareness and retry/backoff strategy

⸻

6️⃣ Deployment
• Production-ready code
• Docker setup (Kubernetes-ready preferred)
• Basic CI/CD guidance
• Brief knowledge transfer session

⸻

Acceptance Criteria
• Clean separation between core engine and adapters
• One provider fully integrated as proof-of-architecture
• ≥99% response consistency during staging tests
• Unit and integration tests covering critical paths
• Clear documentation enabling another engineer to add a new provider independently

⸻

Ideal Profile

You have:
• Experience building scalable backend systems
• Strong understanding of abstraction layers and interface contracts
• Experience designing rule engines or decision-based systems
• Built multi-provider connector platforms before
• Think architecturally, not just implementation-focused

When applying, please include:
• A short outline of how you would structure the architecture
• Preferred language/framework and why
• Estimated timeline for MVP delivery

Also, please briefly describe a past project where you designed a system that integrated multiple external APIs into a unified internal model. What were the key architectural challenges? Along with project examples.