Single Docker Container for Two Processes vs Two Services Connecting to Same DB

"We are considering creating a queue for each microservice and publishing the messages to the queues via SNS."

Yes, then your queues can subscribe to the notification and you no longer need the message service. Essentially its fan out routing. Your microservices become queue workers

However, lots of queues and notifications can become complicated. SQS + SNS is a bit clunky in some respects. I would be tempted to limit my use of it to cases where I definitely have long running async tasks.

If you can fit 4 or 5 micro-services on one ec2 instance because they are all small simple operations that aren't stressed, you've simply separated them for architectural concerns. Then it might be worth just having them call each other when required.

It's very easy to take queues to the nth degree and have millions of nano services communicating via sns messages. It's not that this doesn't work, but you do have to monitor these queues and worry about dropped and double sent messages, full queues, error queues etc.

Deciding if order is important is up to each microservice. In your case, it definitely is. Your example above is actually easy to solve since if the OrderService gets an UpdateProduct event when the product doesn’t exist, it can put the UpdateProduct event back on the queue assuming there’s a Create event coming soon. However, two UpdateProduct events arriving out of order could cause problems so we still have to solve the issue.

There are ways of ensuring order in the publisher and subscriber but they are clumsy. If your Update events contain the entire new state of the product, you can add a timestamp and refuse to update your cache if the incoming timestamp is older than the persisted one. If your Update events only send updated data, you can put an incrementing version number on your aggregate and if an incoming event is more than 1 greater than your existing version, requeue the event assuming the intervening event is coming soon. As you can see, these are clumsy. You’re much better off ensuring order in the queue.

You may consider Azure Event Hub instead of Azure Event Grid. The Event Hub will guarantee order in a single partition, so wisely partitioning your app can give you the order guarantee you need. The Event Hub acts more like Kafka than a traditional Queue in that it provides a queue plus persistence of events for a small number of days. This can be advantageous if a system goes down and needs to recover.