@michaeldrogalis I could see your comments and have replied to them. Let me know if I need to take further action.

And as I commented in the PR, I’d like to have CircleCI tests running against Datomic Cloud…

Cool, Ill finish the review tomorrow. Thanks so much, this is a wonderful contribution @kenji_signifier!

thx, it was a good opportunity for me to learn the differences between peer and client api.

@kenji_signifier Thanks for addressing my comments. Can anyone else take a pass over this PR? Would just like a second pair of eyes on it

With CMDR pattern. Should we use one job and process every command at process-commands task or Submit multiple jobs, each job for different set of commands. 1st case, we end up writing commands implementation in a single job, it becomes painful to deploy and manage commands. 2nd case, As most of the jobs consume from single kafka commands topic, each task of job receives the segments from kafka commands topic, of which one only runs command implementation. Any suggestions?

@sreekanth Where's the real pain behind case (1)? If you're going to process commands in order because they're casually effected, you'll need the same process (e.g. one task in one job) to read them sequentially.

@michaeldrogalis If we have to add few commands and remove commands, we need to stop entire job( all running commands) and to re-run, set offset to last read offset value. trying to avoid this issue.

@sreekanth How sensitive are you to restart latency?

There are some more sophisticated means of deployment via nrepl if its very sensitive

@michaeldrogalis It won’t be a big problem in our case, was looking at other possibilities.

@sreekanth One thing you can do is open an nrepl socket to upload new code for commands. Its obviously a little more tricky, but has the advantage of dynamically loading code without taking the process down

@michaeldrogalis Sure, this clears.

Great. Let me know if I can answer anything else @sreekanth 🙂

Thanks @michaeldrogalis, that’s it for now :)