> If code is kept organized, it can be split into microservices when/if the need arises.
You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code.
You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code.
I can't tell if this is facetious. I hope it is.
It's also perfectly possible to split those things up, and to have them share the same database.
This causes microservice extremists' heads to pop off..
The truth is, most things can be made to work - though there are various trade-offs ("shenanigans") involved.
e.g: In my current project, there's a bit that loads large-ish files, parses/converts the data, and loads them (order of tens of thousands of rwos) into SQL tables.
For reasons that best escape me - since after the files are parsed the entire dataset is _literally_ in memory, instead of doing a bulk sql update there- and then, thousands of messages are enqueued to be consumed by a practically unlimited number of lambda functions that then... bomb out as the SQL database hits it's connection limit and keels over.
I guess those shenanigans have better buzzword compliance!
Batching is the way to go, 100%. Remove the network as much as you possibly can.
(still, that doesn't change the fact the code is badly designed)
So much nicer to expose a documented and versioned API (and/or published event stream), so that the consumers of data your service manages have some flexibility at which moment to migrate to the new schema.