Twitter doesn't really provide me with the space to explain my issue so...
I have three apps all of which consume from a single service. I can easily think of 5 or so responsibilites of the service. In addition to this many endpoints are only used by one app. The code base is small (< 10k loc) and the responsibilites are well isolated. The team is also small and we only have a single ops.
My fear is that splitting the service into more granular services will create more work than its worth due to the ops overhead, need for client libraries, and other complexities that are introduced by using two completly isolated systems.
So what are some indicators that your service is too big and needs to be split up?
My advice may not be popular, but IMHO, if you're not finding your current architecture painful or foresee it being painful with a near future new feature, then don't split it out yet.
To address your direct question: If/when you find that an update to one responsibility requiring a re-deploy of the whole to be a problem, then consider splitting it up. Also if you find that the responsibilities become less isolated, then splitting them up will better enforce that isolation.