API Destinations for Private Endpoints: From Oversight to Insight!

I made a mistake! I was tasked to do a discovery on how we can sync some data from a monolith to a new micro-service and I came up with 3 main solutions and a fallback: Monolith → Event Bridge → API Destination → Exposed endpoint in the microservice Monolith → Event Bridge → SQS ← Polling from microservice Monolith → Event Bridge → SNS Topic → Exposed endpoint in the microservice (Fallback) Microservice → Event Bridge → SQS → Lambda → Exposed Endpoint in the service or directly update the database Justification and Rationale Now I have 2 main reasons on how and why I came up with these solutions: The monolith was already configured to send events to an event bridge One of the requirements was to keep the monolith and microservice loosely coupled Now if you look at the options, the choice is obvious, API Destination!! But let’s still dig a bit deeper as to why? With API Destination, all I need to do is deploy some IaaS, expose an endpoint in the service and done! With SQS, even easier, but polling means the service is always looking for an event. The data to be synced was not something that was changed frequently, but when it did, it was important to reflect the change and the service behaviour quickly. Furthermore even though the setup was easy, it had the complexity of batch processing, deleting messages after they were processed (yes, you need to do that manually with SQS), and the risk of the same message being delivered more than once, so service needs to be idempotent. This was all just too much for a little sync,

Apr 13, 2025 - 13:48

API Destinations for Private Endpoints: From Oversight to Insight!

I made a mistake! I was tasked to do a discovery on how we can sync some data from a monolith to a new micro-service and I came up with 3 main solutions and a fallback:

Monolith → Event Bridge → API Destination → Exposed endpoint in the microservice

Monolith → Event Bridge → SQS ← Polling from microservice

Monolith → Event Bridge → SNS Topic → Exposed endpoint in the microservice

(Fallback) Microservice → Event Bridge → SQS → Lambda → Exposed Endpoint in the service or directly update the database

Justification and Rationale

Now I have 2 main reasons on how and why I came up with these solutions:

The monolith was already configured to send events to an event bridge
One of the requirements was to keep the monolith and microservice loosely coupled

Now if you look at the options, the choice is obvious, API Destination!! But let’s still dig a bit deeper as to why?

With API Destination, all I need to do is deploy some IaaS, expose an endpoint in the service and done!
With SQS, even easier, but polling means the service is always looking for an event. The data to be synced was not something that was changed frequently, but when it did, it was important to reflect the change and the service behaviour quickly. Furthermore even though the setup was easy, it had the complexity of batch processing, deleting messages after they were processed (yes, you need to do that manually with SQS), and the risk of the same message being delivered more than once, so service needs to be idempotent. This was all just too much for a little sync,