5 ms·
Nice article. For those of you working on a SOA project, can I have some feedback on how people manage data sources? For instance, I am in the process of breaki
by why-el 12y ago
Nice article. For those of you working on a SOA project, can I have some feedback on how people manage data sources? For instance, I am in the process of breaking up a monolithic application into small services, but the problem is that most of these services rely on the same data (For instance a search service and an autocomplete service will work with the same data). What are you strategies to deal with this? I mean, is it simply a matter of relying on the same database? How about models built on top of this database and their tests?
- iamartnez 12y agoNothing wrong with two services using the same data source. If data locality is a concern, deploy both services alongside one another. Or you could place the data behind an API. It would speak HTTP/Thrift/whatever and would be solely responsible for handling the data. Front the API with a cache if latency becomes an issue. For your specific example, consider pushing data to autocomplete and search instead of having them pull.
- why-el 12y agoInteresting. Are you aware of any high profile examples of this architecture? For my own case, search and autocomplete use the same modeled data, but autocomplete for instance runs lots of precalculations on this data, so the data behind an API is not really a choice.
- matticakes 12y agocheck out NSQ, designed for (in part) exactly this use case (and also written in Go) http://bitly.github.io/nsq http://bitly.github.io/nsq