> For example, you'd be hard pressed to find a team building AWS services who is not using SQS and S3 extensively I design and develop products that rely on qu

> For example, you'd be hard pressed to find a team building AWS services who is not using SQS and S3 extensively I design and develop products that rely on queuing systems and object storage; if its SQS or S3 is an implementation detail (although S3 is also a de-facto standard). Some of those products may rely on millions of very small objects/messages; some of them may rely on fixed-size multi-MB blocks. Knowing the workload, you can often optimize it in a non-trivial way, instead if just using what the provider has. > The hard part is making this system immediately interpretable and getting "put a message in, get a message out" while making the complexities opaque to the consumer. Not really, no. As you said, is already a solved problem. Aws obviously has different scale requirements than my reality, but by having ownership I also have only a fraction of the problems. > There's nothing about rolling your own version that will make you better able to plan this out -- many of these lessons are things you only pick up at scale. I cannot agree with you on this. As an example, can you tell me which isolation level is guaranteed on an Autora instance? And what if it is a multi-zone cluster? (If you can, kudos!); next question is, are developers aware of this? If you have done any cursory solution design, you will know the importance of mastering the above questions on development workflow.