21–30 of 42 posts
Is there a difference between microservices and SOA? I've used architectures just like this in the past but never heard of "microservices" until recently.
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
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.
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
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.
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
The text makes it seem like they're using SQS for many things, but the diagram only shows it between Orders and Shipments. I guess everything else communicates through the database and HTTP requests? Using SQS means you're either polling or long-polling with hangups every 20 seconds. This seems pretty shitty to me. Also how do you structure one of these services around polling or long-polling to get its info? It soun…
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.
Is there a difference between microservices and SOA? I've used architectures just like this in the past but never heard of "microservices" until recently.
AFAICT, "microservices" is exactly SOA in its original sense; my guess is the rename is because SOA has become so attached to particular XML-based implementations and standards (e.g., the WS-* series of standards).
Earlier quoted context omitted.
Yup we are. There might be multiple applications interested in the event and they each get their own queue.
Have you looked into a "real" messaging queue for this, like RabbitMQ or another AMQP based system for this? Or are you bound to SNS/SQS for a particular reason?
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
If you use RabbitMQ (which are we using in our own microservice architecture), you can use fanout exchanges based on topics to accomplish the same thing more elegantly.
In this topology, every message sent to that exchange gets copied to any queue bound to that exchange.
This system also supports routing via "topics", which are paths that support wildcards; the publisher can publish to "foo.bar.baz", and queues can bind to the exchange using the routing key "foo.*.baz", for example.
We use this to listen to specific events, eg. a specific app is associated with content under the path "someapp.someclient". A data store publishes modification events with "create", "update" or "delete" followed by the path; so the the app, to get the stream of updates, simply listens to "create.someapp.someclient.#", "update.someapp.someclient.#" and "delete.someapp.someclient.#".
The shipment app listens to the messaging system, sees an order take place, looks at the details, and says, "Okay, I need to send two boxes to this person." Any other services interested in an order happening can do whatever they need to with the event in their own queues, and the store API doesn't need to worry about it. I'm curious how you guarantee that all the systems that need to see an event, will actually see…
SQS is very simple and the solution here requires that the publisher knows all the listeners. If you use RabbitMQ (which are we using in our own microservice architecture), you can use fanout exchanges based on topics to accomplish the same thing more elegantly. In this topology, every message sent to that exchange gets copied to any queue bound to that exchange. This system also supports routing via "topics", which…