Credit Decisioning Platform: 20 Microservices in Four Months

We built a credit decisioning platform as twenty microservices across intake, affordability, bureau orchestration, decisioning, limit setting, and explanation.

The four-month delivery window forced a useful discipline. Every service had to map to a real domain boundary. Every boundary had to publish events. Every decision had to be explainable.

The shape

We started from business capabilities, not technical layers. Application intake owned application state. Affordability owned income and commitment calculations. Decisioning owned policy execution. Explanation owned the customer and audit narrative.

Each service had its own contract and test set. Events connected the flow.

What made speed possible

Speed came from constraint.

We used common service scaffolds, standard observability, shared deployment pipelines, and contract testing. Engineers did not spend time inventing service patterns. They spent time on domain logic.

AI-assisted generation helped with repeatable code, but human architects owned the service boundaries and policy interpretation.

What we protected

Credit decisions need evidence. Every decision carried the policy version, data sources, calculation path, and override history.

That meant auditability was not added later. It was part of the domain model.

The lesson

The platform moved quickly because it stayed narrow. Twenty services sounds large. In practice, each service was small enough to understand and important enough to own.

That combination is what kept delivery fast and defensible.

Rejected option.

We rejected a shared decision service that owned too much logic. It looked efficient, but it would have become the new monolith.

Credit decisioning contains several distinct responsibilities: intake, bureau orchestration, affordability, policy, limit setting, explanation, and audit. Combining them would have made change faster at first and slower later.

What held the platform together

Events held the platform together.

Each service published domain events with enough context for downstream services to act without reaching into another database. Contract tests protected the event shape. Replay helped us verify policy changes against previous cases.

The event stream also supported explanation. We could reconstruct why a decision happened without scraping logs from several services.

Production lesson.

Twenty services worked because the boundaries were real.

The number is less important than the ownership model. Every service had a reason to exist, a team that understood it, and a set of events that made its work visible.

That is what kept speed from turning into sprawl.

The operating rule

The rule we kept was simple: the system should make the accountable path the default path.

That meant no hidden side channel, no manual exception that escaped the evidence record, and no output that could not be replayed later. If a reviewer changed the result, the change became part of the same record. If a threshold moved, the previous cases could be replayed before the change reached production.

This added a little ceremony. It removed a larger amount of ambiguity. Engineers knew what evidence the platform expected. Reviewers knew where to look. Operators knew which signal would trigger rollback.

The result was calmer delivery. The team still moved quickly, but each step left a trail strong enough for someone else to inspect weeks later.

The practical value came from making the decision visible at the point where work changed hands. Engineers could see the boundary they were protecting. Reviewers could see the evidence they were accepting. Operators could see the rollback path before production pressure arrived. That shared view reduced the amount of trust the process had to borrow from memory.

That is why we kept the scope narrow. A narrow scope made the evidence stronger, the review simpler, and the next change easier to reason about. The service count was never the achievement. The boundary was.