Authenticating...
Skip to main content

0019: Handle AdGem Outgoing Postbacks

STATUS​

Superseded

Superseded by Resilient Outgoing Postback Architecture, which persists outgoing postback details in PostgreSQL (rather than AdTracking) and adds durable retry/DLQ, self-serve replay + edit, idempotency, and a pluggable hook registry.

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​

This ADR was superseded before its consequences were finalized. See the successor ADR, Resilient Outgoing Postback Architecture, for the current design, alternatives, and risks.