Skip to content

0019: Handle AdGem Outgoing Postbacks

STATUS: Ready for Review

CONTEXT

As part of the old AdGem Redshift instance sunsetting process, we've encountered that the AdGem API outgoing postback feature is tightly coupled to the old Redshift events collection workflow. The event data is saved in memory using the ConversionEvent or ProgressCompletedEvent classes. After it,

This coupling difficulties the old AdGem redshift instance deprecation and also criples the growth of the Outgoing Postback feature.

Considered Options

#### 1. Keep existing logic, but change the connection to the new Redshift instance Pros: - Easy to complete the old Redshift instance EOL. - Persisted events can be retried - Small dev work required. - No downtime expected.

Cons: - It would break the write-only approach taken with the AdActionEvents collection. - Maintain the monolithic approach on the IncomingPostbackController - Limited Outgoing Postback feature growth. - Keeping legacy code.

#### 2. Migrate the Outgoing Postback data to AdGem Postgres DB Pros: - Persisted outgoing postback information simplifies the retrying postback capabilities - Separates the concerns from the outgoing-postback event and the outgoing postback feature - Latency improvement

Cons: - Stores isolated and duplicated from the events table data after the outgoing postback fires

#### 3. Use existing AdActionEventData as a DTO for Outgoing Postback Service Pros: - Standardizes the events object structure - Removes legacy code

Cons: - In-memory Outgoing Postback event information limits the ability to retry the postback - Breaks the Single Responsibility Principle - Maintain the coupling

#### 4. Store the outgoing postback info in a DTO in Redis Pros: - Can apply the Dependency Inversion Principle - Easy to add the retry postback feature - Flexible outgoing postback schema - Latency improvement

Cons: - High lift dev work - Persisted but temporal outgoing postback information

5. Store the outgoing postback details in AdTracking

Pros: - Can apply the Dependency Inversion Principle - Easy to add the retry postback feature - Flexible outgoing postback schema - Latency improvement - Persisted postback details

Cons: - High lift dev work

DECISION

5. Store the outgoing postback details in AdTracking

CONSEQUENCES

Risks

NOTES

References

Original Author(s)

  • Q Soto
  • M Cornejo

Approval date

Approved by

Appendix