Okay well this is getting confusing. I'm going through https://microservices.io/ and they say database per service has a lot of positives for projects that need scaling (which I'm working on) but they require the saga pattern for transactions that span multiple service (which I require) but event sourcing can be used for atomically updating state and publishing messages. The steps are database per service => sagas => event sourcing, but by definition an event store is a single database so event sourcing violates the first pattern
I know this isn't strictly related to your bootstrap but it is related to event sourcing which your project has the most documentation on :p
Ok, it may sound a bit blatant, but I think that Event Sourcing is taught wrongly in general ;)
also messaging and microservices :P
My perspective on that is that the most important is the careful design considering logical and technical split.
So e.g. you can have good logical split into modules and have good monolithic modular app
you can have a mixture (e.g. 2 modules deployed at the same machine, 1 on the other, etc.)
I'm not a huge fan of microservices.io - it has some good content, but it lacks context and more detailed considerations
Sorry for this intro :P
So I think that, I'd personally try to avoid distributed processes unless they're needed
So not do saga just because we distributed databases, and we distributed because we want to do microservices, etc.
In general Event Sourcing is also not a system-wide pattern
it's more of a module-pattern
So understanding of events should be the inner module understanding. Then you can have granular events as much you need.
But if you try to use those events as they are also for cross-module integration then you'll have a leaking abstraction and first step to distributed monolith. Which has all the cons of monolith and all cons of microservices - without pros ;)
or through e.g. some external message bus as Kafka, RabbitMQ etc.
In general command send with pub/sub semantic - so you're publishing command and expecting to get event at some point with success or failure.
I'm not sure about your particular business case, so it's hard to suggest you which would be the best for you. But imho starting with proper boundaries, load analysis etc. is always good starting point ;)
I appologize for a lecture :P
Feel free to ask more questions if that wasn't clear answer ;)
No, no need to apologize this has been wonderful and I appreciate your time spent on me. I feel like I've become a struggling student that sat down with a professor :p I was not even aware that a microservice lives in its own process and spun up with docker or even systemd
I got few scars on that by myself :D
I think that microservice doesn't have to be on docker
it could be a set of VMs
But the common practice is use docker or kubernetes
as it allows easier orchestration
I feel more comfortable with systemd however, is that useable
I'm not sure if you're planning to use AWS but Aurora DB is an interesting concept
It allows different engines - e.g. Postgres, MySQL
and provides scallability around that
Cool, however I feel like starting with a microservice project is like hitting the ground running, and also traveling 30 miles and hour while doing so. My question is, is your GoldenEye bootstrap monolithic? Because I might actually use that so I don't shoot my foot aiming for the ground