There is currently a race condition in the specification as follows:

• OrderProposal is created
• OrderProposal is approved
  (Orders feed updated with OrderProposal)
• OrderProposal is booked, and creates a new Order
  (OrderProposal is deleted from orders feed)
• Order is cancelled
  (Orders feed updated with Order)

The reason for the previous OrderProposal is set to "state": "deleted" in the Orders feed at B is to prevent a race condition where B is also updated in the Orders feed at the same time as it is updated by the response from B.

In order to create one Orders feed, the same database table must be used to represent both OrderProposal and Order:

• Orders use a broker supplied UUID as their primary key
• This means that storing the OrderProposal and Order in a table requires either (a) the primary key to be a compound key of "Order type" and "UUID" or (b) the same row in the table to be reused for both.
• (b) is chosen, there's a risk that OrderProposal deletions are not picked up upon immediate cancellation, reusing the same UUID risks creating issues for downstream brokers storing both Orders and OrderProposals.

This is potentially resolved by simply allowing the Order to overwrite the OrderProposal in the RPDE feed if it has the same UUID. However, this requires Brokers to treat an Order as replacement to an OrderProposal with the same UUID, which is a "hack" on the abstraction, and is likely to create problems as the specification evolves.

This also creates implementation challenges for systems that store the Order and OrderProposal in different tables, as they need to be combined into one table to power an single RPDE feed.

The cleanest solution to this is likely to create a new feed: /order-proposals-feed which contains only OrderProposal.

Advantages:

• Creates flexibility for implementing systems, which can power both feeds from a single Orders table, or from two different tables, depending on their internal architecture.
• Removes issues around race conditions for (b) above
• Removes requirement for implementing a compound key for every implementation
• Clearly maintains the semantics of a "deleted item" in the feeds - as it's clear that either an "Order" or "OrderProposal" is being deleted depending on the feed
• Ensures the @id namespaces of the Order and OrderProposal are also separated into different feeds, which ensures a pure conceptual separation between the two types.

Disadvantages:

• Requires more polling in production