Object oriented design discussion/review

Requirements: Index of items needs to be created or updated if already present. This index can be of two types:

1. For a document (to index its contents): DocIndex
2. For a document container that can contain many documents (to index contents of all documents in the container): ContainerIndex

DocIndex creation can be via:

• UI
• API

ContainerIndex creation can be via:

• UI
• API

Additionally, DocIndex can also be created as part of ContainerIndex creation, via both UI and API.

Also:

1. The initial "setup" is different for both DocIndex and ContainerIndex.

2. The core algorithm is "mostly" same for generation of both DocIndex and ContainerIndex, with the exception of some minimal differences in certain steps. Examples of differences:

   2a. An alert is required at a point in the code flow when DocIndex is generated via UI, only if it's not generated as part of ContainerIndex. API route has no alerts for both.

   2b. There is no logging required for ContainerIndex (for now), but DocIndex requires different logging in the following routes:

   2b.1. create via UI

   2b.2. create via API

   2b.3. update via UI

   2b.4. update via API

To model the above system in an OO design , I considered the following design patterns (and their variations thereof):

1. Template Method: Have a base Index class that enforces the common algorithm structure and model the differences in the derived DocIndex and ContainerIndex classes. This could not handle the behavior that alerts need to be shown in a step when DocIndex is created via UI, but not when it's created via UI as part of ContainerIndex.
2. Strategy: Model the differences with composition. However, I think my requirements aren't in line with the intent of Strategy design pattern as I don't want different algorithms but want to model differences only in certain steps. The algorithm structure is generally the same for both DocIndex and ContainerIndex creation.
3. Decorator: Again IMHO its intent didn't match my requirements as I don't want runtime change in behavior. Also, this might require a lot of changes as the existing code has many other callers as well.
4. State: To me this looks most promising. What I'll do is maintain different states of the index like UIContainerIndex (when container index is created via UI), UIDocIndex (when doc index is created via UI), UIContainerDocIndex (when doc index is created as part of container index via UI), and similar three states for the API route. This does satisfy my requirements, but I feel this might get unwieldy as the number of states increases (it already looks "not good enough" to me).

It would be great if someone could suggest something better. Thanks.