Synthetic Economy

An n8n workflow runs every 5 minutes, taking an existing customer from the database, running some code, and then (or not) placing an order.

The basic model is:

Customer traits + random variation + available products = generated order

Each time the n8n workflow runs:

1. One existing customer is selected randomly.
2. Their buy eagerness determines whether they place an order.
3. If they buy, their spend eagerness determines approximately how much they spend.
4. Available products are selected to build a basket near that amount.
5. The basket and existing customer are sent to BFshop.
6. BFshop validates and records the order through its normal order service.

A workflow execution can therefore produce either no order or one order belonging to an existing customer.

Each customer has two persistent behavioural traits stored in Neon:

Buy eagerness: 1–10

Spend eagerness: 1–10

These values are generated once and remain attached to that customer.

Buy eagerness represents the customer's likelihood of buying when selected.

The calculation is:

Purchase probability = buy eagerness ÷ 10

Examples:

• Buy eagerness 1 = 10% chance of buying
• Buy eagerness 4 = 40% chance of buying
• Buy eagerness 7 = 70% chance of buying
• Buy eagerness 10 = 100% chance of buying

A customer with a buy eagerness of 7 does not necessarily buy seven times during a particular period. They have a 70% chance of buying each time the workflow selects them.

Spend eagerness represents how much the customer is inclined to spend when they buy.

It is converted into a target between two configurable values:

Minimum order value: 20

Maximum order value: 500

The customer's spend eagerness places them proportionally between these minimum and maximum values.

The calculation is:

Random variation of plus or minus 20% is then applied.

This means the same customer does not spend exactly the same amount every time.

A customer has:

Buy eagerness: 4

Spend eagerness: 3

They have a 40% chance of purchasing when selected.

Their base spending target is approximately 126.67 currency units.

After the random variation is applied, their target will usually fall between approximately 101 and 152 currency units.

An order worth 120 currency units is therefore consistent with their behaviour.

The workflow follows this sequence:

1. The n8n schedule triggers the workflow.
2. A Postgres query retrieves a random customer and the available products.
3. The Code node performs the buying decision.
4. If the customer buys, the Code node calculates a spending target.
5. The Code node constructs a basket using available products.
6. An HTTP request sends the proposed order to BFshop.
7. BFshop's existing generated-order service validates and records the order.

The Postgres node retrieves:

• One randomly selected customer
• The customer's buy and spend eagerness values
• All products with stock available
• Each product's ID, price and current stock level

Customers are selected uniformly. Every customer has approximately the same chance of being selected.

Buy eagerness affects what happens after selection. It does not affect the likelihood of being selected.

The Code node generates a random number between zero and one.

This number is compared with the selected customer's purchase probability.

If the random number exceeds the purchase probability, the customer does not buy and the Code node returns no output.

Returning no output prevents that workflow execution from reaching the HTTP Request node.

Unsuccessful purchase opportunities are not currently recorded.

If the customer buys:

1. A target order value is calculated from their spend eagerness.
2. Products without stock are removed.
3. The remaining products are placed in a random order.
4. Products are added while there is space in the target budget.
5. Quantities are limited by the remaining budget, available stock and configured maximum quantity.

The current limits are:

Maximum number of different products: 5

Maximum quantity of one product: 5

A product is skipped if one unit would exceed the remaining target.

If no product fits within the target, the cheapest available product is added. This ensures that a customer who passes the buying decision produces an order. In this situation, the final value may exceed the original target.

The Code node produces three groups of information:

Customer

• ID
• Name
• Email
• Address
• Age
• Gender

Order items

• Product ID
• Quantity

Simulation information

• Buy eagerness
• Spend eagerness
• Target spend
• Estimated spend

Only the customer and order items are sent to BFshop.

The simulation information remains available in n8n for inspecting and debugging workflow executions.

n8n proposes the order, but BFshop remains authoritative.

The generated-order service:

• Finds the existing customer by ID
• Retrieves the authoritative product records
• Uses server-side product prices
• Checks available stock
• Calculates each order-item total
• Calculates the final order total
• Writes the order and its order items to the database

This prevents n8n from becoming authoritative for prices or recorded totals.

The customer ID is the authoritative customer identifier. Names are not unique, so two people named Jack Thompson are still treated as separate customers.

New customers receive random buy and spend eagerness values between 1 and 10 through database defaults.

BFshop does not currently read or write these properties through Prisma. Neon assigns them automatically when a customer is created.

The synthetic economy can produce:

• Customers who buy frequently and spend heavily
• Customers who buy frequently but spend little
• Customers who buy infrequently but spend heavily
• Customers who buy infrequently and spend little
• Returning customers with repeated order histories
• Natural variation between orders from the same customer

• Orders are unrealistic; one may contain an apple, two beds and mascara for example
• No more than one order can be created per run.
• Product selection remains random.
• Customers do not yet have product or category preferences.
• Age, gender and location do not currently influence behaviour.
• Buy and spend eagerness are initially assigned randomly.
• Failed buying opportunities are not recorded.
• The spending target is approximate because stock and product prices constrain the basket.
• The small historical name pool has produced duplicate names.
• Names and genders were previously generated independently, producing some unrealistic combinations.
• Only one customer is considered during each workflow run.

These are limitations of realism rather than failures in the ordering architecture.

Demographic information may later influence the probability with which behavioural traits are assigned.

The future sequence could be:

Age, gender and location → trait probabilities → buy and spend eagerness → purchasing behaviour

Product preferences could form another independent behavioural layer:

Customer traits → purchase frequency, spending amount and product or category preferences

These additions would increase the realism of the synthetic economy without replacing the core selection, purchasing and order-placement workflow.