Aampere · Supply Backbone
01 / 09
01 / 09
Platform Architecture Proposal

One backend,
five supply streams.

Seller Funnel and Dealer Platform are glued together today by direct calls and a CRM standing in for truth, built for exactly one supply source. That breaks the moment supply becomes plural. This is the backbone that replaces it, and the path to get there without a big-bang rewrite.

01  The problem

One glue layer, one assumed source

The two products talk through direct service calls, a shared photo bucket, and a CRM both sides read as metadata ground-truth of the car. That works when there is exactly one supply source. The 2027 target adds four more (B2B, leasing returns, trade-ins, external platforms) sharing one backend, with the same trust guarantees: no duplicate listings, correct state, real-time execution speed.

Today's assumptions result in problems
  • CRM's stage model is seller-shaped. Other streams don't fit the C2B process and need customization.
  • No read / write synchronization or transactions. Multiple backends introduce complexity regarding information handling processes. Nothing stops two streams claiming the same VIN independently.
  • “Add an API” = N×M again. Each new stream is another bespoke integration, not configuration. There is no fundamental abstraction that can serve all backends.
02  Why this, not that

Upstream of every other risk

Bad or duplicated intake data makes an untrustworthy auction, no matter how sound the bidding mechanics are. It's the data-consistency precondition the valuation ML model needs, and it's where partner-feed deduplication naturally lives. Target volume (~30k requests/month) also shows that the biggest problem is not scaling. The real risk is structural: can the architecture absorb new streams, personas and countries without breaking correctness and trust.

Considered, set aside
  • Bidding mechanism — mechanics already sound; fixes a symptom, not the source.
  • Valuation → ML core — high long-term value, but not as critical as a solid backend for now.
  • Cross-border settlement — a real legal risk, but a rules-engine problem, not an architecture centerpiece.
03  Today

Point-to-point, with a CRM standing in for truth

Seller Funnel C2B intake · pricing Dealer Platform listing · blind auction direct calls · comparable bids, photos, listing metadata CRM treated as “source of truth” for vehicle stage writes stage writes stage Trade-in intake (new) dealer persona, in progress forced into seller-shaped fields
Every new supply source means another point-to-point integration, and the CRM built for pipeline tracking becomes the de facto, unreliable record of vehicle truth.
04  Target architecture

One backbone, pluggable producers

C2B (Seller Funnel) Dealer trade-in B2B supply Leasing returns External platform Backend Event-based; Serverless; Decentralized Identity Management resolve identity Vehicle Ledger emits VehicleStateChanged events Auction Core VehicleReadyForAuction ⇄ AuctionOutcome CRM (sink only) ops UI, one-way
Producers only ever talk to the bus. Identity, state, and auction each have exactly one owner; the CRM becomes a one-way sink (for UI and backward compatibility) instead of a shared source of truth.
05  Contracts & ownership

What holds everything together

The interface, abstracted

Every producer emits against one abstract interface, not a bespoke one per stream: a process-agnostic data structure that says what a supply event is, not how any one stream happens to produce it.

Abstract interface Process-agnostic data structure Canonical identity resolution Versioned, backward-compatible
Ownership boundary
  • Supply Adapters own intake UX and validation, per stream. Never identity or state.
  • Identity & Ledger own “is this the same car” and “what stage is it in.” The only two sources of truth in the system.
  • Auction Core owns bidding mechanics only, subscribes to the bus.
06  Migration path

Five phases, each shippable alone

01

Shadow mode

Publishes in parallel with the CRM. Zero behavior change.

02

Ledger parity

Vehicle Ledger shadow reads the bus; a parity job proves it matches the CRM before any read path cuts over.

03

Second producer

The in-flight trade-in flow joins as producer #2 on the same contract — the real generalization test.

04

Identity & scale-out

Deduplication service goes live; leasing-returns and external-platform adapters wired on the proven contract.

05

Retire the CRM

Direct service calls removed. CRM keeps a sink connector for ops — out of the write path entirely.