development programming

Inflection points

An inflection point comes where there is a dramatic change in direction. In a typical business or software process, this is the fulcrum around which the rest of the process rotates.

They’re often easy to spot by looking at the before and after. For a typical shopping scenario, the inflection point is the buy now point. Everything before that is sales, everything after is fulfillment.

Some processes may also have secondary inflection points. Broadband provisioning for example has one inflection point where the order is confirmed, a fulfillment process that may involve site visits, transfer of your number from your previous provider and other preparatory work, and then a second inflection point once everything’s ready and you start paying line rental and usage fees.

Inflection points in software

The reason I’m interested in this at the moment is that these can be unnecessarily complex things to model in software.

We have a natural tendency, especially in domain driven thinking, to simplify the mapping between the business and software domains, so that we can reduce the cognitive load switching between the two.

For inflection points, this simplicity of mapping can easily lead to additional code complexity.

For a typical physical sale, most of the following will occur at the point the user hits the “buy” button :

  • Verify payment
  • Decrement stock count
  • Send confirmation email
  • Trigger warehouse workflow
  • Trigger delivery workflow
  • Redirect user to confirmation page

Like all good developers, we’ll break these down into functions so we can test each step individually, we’ll put the payment options, the warehouse and delivery systems and email behind interfaces so we can mock them out. But we’re still doing too much.

Decoupling inflection points

We have a single user interaction with a lot of side effects, making it harder to reason about, delaying the user response and coupling the success of the interaction to multiple external systems. Yes, the payment provider is essential in creating the order, but does it break the order if the email, warehouse and delivery components don’t start until several minutes later?

There is an opportunity here to use event listeners or scheduled tasks or other asynchronous processes to decouple the success of the order from the other systems. It means that the steps in the business process aren’t as easy to follow, so the triggers for the consequentials need to be clear (“all orders without a delivery workflow should have one created”), and this approach definitely prefers pull conditions rather than push conditions, so each step knows what it depends on, but not what depends on it – the payment process now only cares that it creates an order, not who fulfils that order.

How do you deal with your inflection points?

3 replies on “Inflection points”

I liked your post Craig, as always. However, I have to say that inflection points seem to be self-inflicted, especially on the example you mentioned. above. All these actions you describe should be totally decoupled and asynchronous to the payment. What the user is concerned about is paying to complete the transaction. Everything else can be send to a queue, a message bus etc in order to execute upon success or failure of the payment. Infliction points can be eliminated or, at least, reduced to minimum using good architecture. Just my $0.02. Thanks for the post again


I think inflection points are always self-inflicted, but it’s not always obvious that’s what’s happening.

It’s easy to look at the requirement and say “this is part of the payment process” without thinking through the implications of it. There’s plenty of creeping complexity around this (see my follow up post too).

I wrote this post to try and highlight it, to help remind me and others to look out for the slippery slope when we start to slide.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.