ℹ️ Context & info

The main business unit of our application is the concept of “Episode”. An episode is composed by a nested structure of:

• Episode
  • Parts
    • Items
      • Blocks
        • Block Fields
        • Media

As a User, I am not imposed any limits on the number of children of each of these elements, all of them have a One-to-Many relation between a child level and its parent (one Episode can have zero or many Parts, one Part can have zero or many Items, and so on…), which makes Episodes potentially infinite in size.

Considering the table structure below:

Each Episode can contain numerous Parts, and a Part is linked to only one Episode. The Parts in turn have a specific positioning within an Episode, this positioning being unlimited and proportional to the number of Parts that an Episode has. This position is registered as an integer under the position column.

The Episode can either have some of its Parts deleted, or have new Parts added to it. Parts, in turn, can be added to the Episode in any position, that is, they can be added at the beginning of the Episode, at the end of the Episode, or between already existing Parts.

Below is a simplified example of how these positions are related to Parts:

💡Assignment

Imagine that a team is working on a specific Episode, with several users editing it simultaneously. They are either deleting existing Parts or adding new Parts at the beginning, end or in between other Parts.

• What potential actions do you identify as requiring a recalculation of positions in the Parts linked to the Episode?
• What API Request payload structure would you use to reliable place the Parts in the position they should end up on? Consider separate endpoints to add, delete and sort Parts.
• Implement the calculation of the new positions for Parts when changes are performed that affect them.
• Do you have another approach on how this can be tackled efficient and reliably at scale?

👽 Requirements