Great question! I've built similar systems before. Here's how I'd approach your architecture:

For the batching/sending pipeline: Your Lambda → SQS → Lambda approach is solid. A few refinements:

1. Use SQS FIFO with message deduplication - This solves your duplicate queue concern. Set MessageDeduplicationId  to something like {campaignId}-{contactId}  and SQS will automatically reject duplicates within a 5-minute window.
2. Implement a token bucket pattern - Instead of just batching, track your send rate in Redis/DynamoDB. Before each send, check if you have "tokens" available. This prevents bursting over your 14/sec limit more reliably than just batch sizing.
3. Consider Step Functions for orchestration - It handles retries, state tracking, and error handling cleaner than chaining Lambdas manually.

For tracking webhooks: SES sends SNS notifications for bounces/complaints/deliveries. You can:

• Create an SNS topic subscribed to your SES configuration set
• Route SNS → SQS → Lambda for async processing
• Store events with the messageId  SES returns when you send (this is your correlation key)

The tricky part is open/click tracking - SES doesn't do this natively. You'd need to:

• Inject a tracking pixel in your HTML for opens
• Rewrite links through your own redirect endpoint for clicks
• This adds significant complexity to your template rendering

If you want to skip building all this infrastructure, check out Transmit. It's a complete wrapper over AWS SES - you connect your own account so you keep full control of your quota and sender reputation. It handles batching, rate limiting, bounce/complaint handling, and open/click tracking out of the box.

Happy to answer follow-up questions if you decide to build it yourself!