title: Microservice Architecture- cross-domain chattiness
body: <p>I have a relatively new project that employs a microservice architecture. I feel pretty good about the size and granularity of the individual services, with the exception or our security service.</p>
  
  <p>I have three main services, let's say <code>foo-service</code>, <code>bar-service</code>, and <code>baz-service</code>. These services never need to communicate, but all three services regularly talk via HTTP requests to the <code>security-service</code>. I want this to stop for a variety of reasons- the biggest is that each request to my individual services spawns a request to the security service, which can turn into several extra hops once you account for load balancing, etc. I've been reading "Software Architecture Patterns" by Mark Richards, and he recommends in these instances you should share databases and violate DRY: copy the required functionality into each service. Still, he uses this example with smaller "utility" classes, which may not really apply in this instance. </p>
  
  <p>The security service isn't that big, so I could definitely copy it into each of the other services. That said, it's just big enough that I don't feel great copying and pasting it - 314 'relevant' lines of code according to coveralls (java so there's a lot more actual code ;-). I could easily turn it into a module that each service brings in- but then my services have a shared dependency and that has bit me in the past. Of course the security code will grow over time as we add authentication methods, but we aren't reinventing the wheel when it comes to auth so It's mostly integrating with other libraries and authentication services. That is, I don't imagine this particular code base getting huge.</p>
  
  <p>So my question, should I copy and paste the code or build a module that every service brings in? Thanks!</p>