Text
Oddworks + Oddcast = ❤
by Blain Smith
When we decided to rewrite Oddworks we wanted to keep some of the original patterns from the original. Most notablely the pattern matching for defining logic and connecting that logic with a common message bus. This also allowed us to embrace the service oriented architecture (SOA).
Oddcast 
Oddworks services communicate with each other with Oddcast message bus channels. Those channels can be set up on top of any type of communication method like TCP, pub/sub, queues, etc called “transports”. The most basic form of a transport is an in-process transport in which all messages are sent around within a single Node process. Our Example Single Process Server illustrates this very well.
If, for some reason, you needed to disrtibute Oddworks across multiple servers you lose the ability to use the in-process transport. This is where you would need to chose another type. The Oddcast TCP Transport is the next step up you could leverage. With this you could deploy the Oddworks Catalog API server on one machine and the Oddworks Identity API server on another machine and have them communicate over TCP, but put them both behind the same domain. This would allow you to scale up/down each service individually based on your needs. For instance, maybe your Identity Service gets heavy traffic you could add a caching layer in front of just that service and leave the others alone.
This is merely the beginning of the flexibility Oddworks offers by using Oddcast to communicate. You can start by deploying a small single server instance and scale up accordingly by breaking out the serverices into their own separate processes and eventually their own servers and coninually to scale horizontally.
If you have any questions please join us in Slack!
Futher Reading: