How would you redesign the integration if it was found that: the contract number is not unique (50-100 duplicates), acquiring is slow, and search takes 3-5 minutes?

If the contract number is not unique and there are multiple duplicates, and the acquiring process is slow, taking 3-5 minutes to search, the integration should be redesigned considering the following steps:

1. Ensure the uniqueness of the key. The contract number cannot be used as a unique identifier. It is necessary to:

   • Introduce an additional unique identifier (for example, UUID or internal ID).
   • Use a composite key that includes the contract number and, for example, the date or another unique characteristic.

2. Optimize data search and handling:

   • Add indexes on fields used for searching.
   • Cache frequently requested data to reduce load on the acquiring system.
   • Consider pre-aggregation or denormalization of data to speed up queries.

3. Improve interaction with the acquiring system:

   • Implement asynchronous request processing to avoid blocking the system during wait times.
   • Use message queues for processing payments and requests.
   • Optimize the acquiring API if possible, or consider alternative providers.

4. Monitoring and logging:

   • Implement performance monitoring and logging to identify bottlenecks.

Thus, the key is to move from using a non-unique contract number as an identifier to more reliable keys, optimize queries and the architecture of interaction with the acquiring system to improve speed and reliability.