iain_hecker

That's where SNS comes in. We publish to SNS which will fan out to multiple SQS queues. When a new service is built, it says to SNS "subscribe my queue to these topics". The publisher of the event doesn't know about the subscribers.

This. Also SOA means STD in Dutch, so we don't want to use it that often ;)

We use SQS for basically everything that happens asynchronously to the main flow. So when a user signs up there are a bunch of things that need to happen straight away (create an account, give 100MB to every new user), these go via HTTP. The others (email, give the owner of a Karma an additional 100MB and a push notification) goes through SNS and SQS.

All these async things don't impact the main flow of the user, so it's no problem that it isn't instantaneous. We are running background processes that do this.

We only use Rails for our frontend applications, they don't contain any business logic. Our backend processes are usually Sinatra for HTTP requests, or custom daemons.

Each app gets their own queue. So there is a queue for the shipment app and for the mailer app. When an event is published to SNS, it gets added to both queues.

Yup we are. There might be multiple applications interested in the event and they each get their own queue.

We will! There are however a couple of really nasty issues that we don't feel comfortable to release to the public yet.

It's easier to test individual items, for sure. Testing small code bases is the best thing ever. However, some actions require stuff to happen in multiple services.

There are "contracts" on how to talk to other services. You can test if you follow that contract, but it's hard to verify automatically that these contracts are in sync between apps.