Extended clients for Kotlin – closing a gap in the AWS ecosystem

Amazon SQS and SNS limit the size of a message. For larger payloads there is the claim-check pattern: the payload lives in S3 and only a small pointer to it travels through the queue. AWS ships this as ready-made libraries – but only for the AWS SDK for Java.

Kotlin teams on aws-sdk-kotlin therefore either run a second SDK with all its dependencies side by side, or rebuild the pattern themselves. On top of that, the Java libraries pull in older Jackson versions for which the GitHub Advisory Database lists seven advisories, three of them rated high.

Translating the Java code line by line would have worked, but it would have been bad Kotlin. My goal was a client designed the way you would design it in Kotlin from the start.

• One class instead of two. aws-sdk-kotlin is built on coroutines – separate classes for synchronous and asynchronous calls are unnecessary.
• 1150 lines of pass-through code disappear. In Kotlin, interface delegation handles this in a single line.
• No more Jackson. kotlinx.serialization serializes the S3 pointer – the Jackson advisories do not affect this code.

class SqsExtendedClient(
    private val sqsClient: SqsClient,
    private val clientConfig: SqsExtendedClientConfig,
) : SqsClient by sqsClient {
    override suspend fun sendMessage(input: SendMessageRequest): SendMessageResponse { /* ... */ }
    // + 7 more methods with real logic – the rest of the interface
    //   is forwarded automatically by "by sqsClient"
}

SqsExtendedClient and SnsExtendedClient are full aws-sdk-kotlin clients and work anywhere a regular client is expected.

The core of the three libraries was written in one afternoon. Tests, license review and release came afterwards – and that is where the real value lies.

• Licenses: s3overflow is an independent new implementation. sqsoverflow and snsoverflow are declared as derivative works of the AWS libraries, with attribution in every file as the Apache 2.0 license requires.
• Limits: The Kotlin clients are not wire-compatible with the Java libraries. The documentation states this openly.
• Tests: Integration tests verify the behavior against a local AWS emulator. Every release carries signed provenance.

All three libraries are open source and published on Maven Central. Adding one takes a single line of Gradle:

implementation("com.christoph-sens:sqsoverflow:1.1.0")

The AWS Java libraries are still maintained and remain the right choice for Java services. The new clients do not replace them – they close a gap for Kotlin.

Technical deep dive: Large SQS and SNS messages in Kotlin.

• Identify the actual gap instead of managing symptoms.
• Design a solution for the target platform instead of mechanically porting someone else’s code.
• Use AI for speed and own the result – with license review, tests and a traceable release.

Is your team missing a building block that so far only exists for another platform? Get in touch.