Be careful with reimplementing with 2PC and mixing events with commands.
You can handle this situation without the orchestrator and without necessarilly worrying about distributed transactions by using the order status.
When the ORDER_CREATED event is emitted after the Orders Service receives the Create Order command, the Order will be in Submitted status.
The Inventory Sevice receives the ORDER_CREATED event, checks for inventory, and either emits an INVENTORY_RESERVED, INVENTORY_RESERVATION_FAILED, or no event (if it crashes, for example).
If the Orders service receives the INVENTORY_RESERVED event, it updates the order status to Reserved, and emits an ORDER_RESERVED event.
If it receives the INVENTORY_RESERVATION_FAILED, the business rules would dictate what to do next. In the simplest case, it updates the status to Failed and emits an ORDER_FAILED event.
If no event was received, now it gets interesting. If you have a Choreographer service, it can detect that no subsequent INVENTORY_* was seen for the ORDER_CREATED event and it can determine what to do next based on the business rules.
Alternatively, an Aged Orders Service can check for Orders in Draft status that are older than a certain time frame. This service can handle cases where an event was never received by the Orders service and potentially emit an AGED_UNRESERVED_ORDER_DETECTED event. Again, it depends on the business rules.
The difference between the last two is that the Orchestrator would probably have its own data store and set of rules for counting events across multiple services. The Aged Orders Service can simply interrogate the Orders Service on a schedule.
Many ways to slice and dice this.