One of the mistakes I see happen in discussions about architecture is that just because something is scalable doesn't mean that's always the only (or even primary) reason for choosing that approach.
I use DynamoDB, not because it is scalable, but because it's a simpler developer experience that covers my rather simple query use cases.
Many teams adopt a multi-service architecture (not always "micro" services) not because of scalability, but because it allows multiple development teams to work and release separately (most of the time).
Don't let arguments of scalability and performance distract you from other considerations.
Comments
One of the mistakes I see happen in discussions about architecture is that just because something is scalable doesn't mean that's always the only (or even primary) reason for choosing that approach.
I use DynamoDB, not because it is scalable, but because it's a simpler developer experience that covers my rather simple query use cases.
Many teams adopt a multi-service architecture (not always "micro" services) not because of scalability, but because it allows multiple development teams to work and release separately (most of the time).
Don't let arguments of scalability and performance distract you from other considerations.