Skip to main content

ADR-014: Backend Language Divergence Accepted

Status: Accepted Date: 2026-03-16

Context​

PowerSeller X is built on Python 3.12 / FastAPI. PSSaaS is built on .NET 8 / C#. Both products operate in the mortgage secondary marketing domain and share concepts like loans, pricing, investors, and LLPA calculations. The team considered whether to standardize on one backend language or accept the divergence.

Options considered:

  • Standardize on .NET: Rewrite PowerSeller X in .NET. Cost: massive rework of a working product.
  • Standardize on Python: Build SaaS App in Python. Cost: lose .NET advantages for PB port (see ADR-001).
  • Accept divergence: Different products, different teams, different stacks. Shared concepts via API contracts.

Decision​

Accepted. Different products, different teams (future), different performance characteristics. Shared domain concepts live in API contracts (OpenAPI specs), not shared code libraries.

Key principles:

  • No shared business logic libraries across products — each stack implements its own domain logic
  • Shared concepts defined in specs: LLPA calculations, MISMO field mappings, loan schemas, and other shared domain concepts are defined in language-neutral specifications
  • API contracts are the integration layer: OpenAPI specs define the interface between products
  • Each product optimizes for its own needs: PowerSeller X optimizes for marketplace throughput (Python async). SaaS optimizes for financial precision and SQL Server interop (.NET).

Consequences​

Positive:

  • No forced rewrite: PowerSeller X continues to work in Python without disruption
  • Best tool for each job: .NET for financial precision and PB port, Python for marketplace and data processing
  • Independent deployment: Products can deploy and scale independently
  • Team autonomy: Future teams can specialize in one stack

Negative:

  • Duplicated domain logic: LLPA calculations, MISMO mappings, etc. must be implemented and tested in both Python and C#
  • No shared libraries: Cannot share a "mortgage-common" package across products
  • Specification maintenance: Language-neutral specs must be kept current and validated against both implementations
  • Knowledge fragmentation: Developers must learn both stacks to work across the ecosystem