Credix: Traceable Credit Workflows at Scale

About Credix – Credit Infrastructure for B2B Commerce

Credix provides credit for the B2B sector, but it doesn't look like a traditional loan. It works more like buy now, pay later for businesses. Credix partners with large distributors (internally called sellers) who, because credit is so scarce for small businesses, have historically had to build and run their own credit operations. Credix takes on that burden: the credit risk, the operational complexity, and the technology behind it, so sellers can focus on selling.

Two promises sit at the center of the business. First, Credix gets new buyers approved in minutes, using its own private credit models and data pipeline to produce a rating and credit limit for any new buyer. Done by hand, that process can take credit specialists days. Second, sellers get paid the day after a purchase, even when the buyer pays over 30, 60, or 90 days in installments.

Use Cases: Durable Underwriting and Batch Credit Decisions

Credix runs DBOS in its buyer onboarding and underwriting process, its first production use case:

Buyer onboarding and underwriting. When a buyer wants credit to purchase from a seller, Credix has to decide whether it can safely work with them and how much credit to extend. That means gathering credit history from multiple external data providers, running the results through risk models, calling out to a third-party low-code platform and waiting for its result, and making room for manual overrides from operations analysts.

Batch underwriting at scale. Credit decisions don't only happen at onboarding. A buyer who goes delinquent may be disabled, then re-enabled once they pay. Batch underwriting runs re-evaluate buyers in bulk, with a single parent workflow fanning out to more than 1,200 child workflows.

Challenge: Choreography Without Orchestration

As Credix scaled and launched new products, its event-driven architecture began to show strain:

Hidden workflows. Most of Credix's processes lacked explicit orchestration. Multiple services mutated the same entities, and each had to work out where an entity was in its lifecycle. Every new product added edge cases that were harder to maintain and harder for the operations team to untangle when manual intervention was needed.

Unreliable external dependencies. Underwriting depends on many third-party data providers, each with different performance characteristics. APIs fail, requests get throttled, and tokens expire without warning. In a distributed, event-driven setup, figuring out what broke and how to recover was difficult.

Traceability across two codebases. Credix runs two codebases, each backed by its own Postgres instance: Python owned by data scientists and risk analysts, and a TypeScript core API that holds the source of truth for orders, balances, and credit limits. Work often starts in Python and finishes in TypeScript, and the same credit outcome can be triggered by many paths, automated or manual. Credix needed to know who made a change, in what context, and where it came from.

Recovery tooling. When something failed mid-process, the team needed to be alerted and informed what failure occurred, and how to resume it efficiently to bring the operation to completion.

‍"If we do this in an event-driven, distributed fashion, it becomes very hard to debug what broke and how to recover from failure. This is where DBOS enters the stage." — Roney Gomes, Head of Engineering, Credix

Solution: Parent-Child Workflows Across Codebases

Credix chose underwriting as a proof of concept for DBOS. Here's what made it work:

Named, explicit workflows. DBOS let Credix model its processes as workflows with proper names and well-defined steps, making the process visible in both code design and architecture instead of implied by a chain of events.

Cross-repo lineage built in. Rather than having a Python workflow call an HTTP endpoint and stitch the results back together later, Credix uses the DBOS client in its data science apps to directly invoke workflows defined in the TypeScript core API. Because DBOS supports parent-child relationships between workflows, traceability comes automatically, even across languages and codebases.

‍"We decided to use the DBOS client in the data science apps to directly invoke workflows defined in the core API, so that we automatically have traceability of where things are coming from." — Felipe Martins, Senior Software Engineer, Credix

Observability and recovery through Conductor. DBOS Conductor shows the relationship between parent and child workflows. Credix tags each child workflow with custom attributes to identify the entity it affects, and when a workflow fails, the team forks it to try again instead of leaving it running indefinitely or retrying by hand.

Results: Thousands of Workflows per Day

Credix runs roughly thousands of underwriting workflows per day. Its largest batch underwriting runs fan out to more than 1,200 child workflows, each one traceable back to its parent and recoverable on failure.

Next, Credix plans to expand DBOS to other use cases and share the approach with its data science team. The goal is to keep giving data scientists ownership over the apps they build, with DBOS supplying the resilience and reliability patterns that experienced software engineers would otherwise need to enforce.

‍"DBOS is an opinionated framework. Sharing that approach with our data science team will make it easier for them to write correct code that runs in a resilient way in production." — Felipe Martins