4 ms·

Well, I mean really most of the micro service architectures are just monoliths with network calls between the components.

• b20000 4y ago
  yeah, so what about locking? it must be a nightmare to make sure that the components all work together as intended...
  • Kamq 4y ago
    > yeah, so what about locking? POST /lock This is only a slight exaggeration over some of the stuff I've seen people try to pull.
  • xwolfi 4y ago
    So, normally, you do not need to lock. If all your services are single threaded, and you have a good transactional model, you only need to duplicate services to create parallel routes. You need to lock when you write a shared area from multiple sources with no opinion on write ordering. But say your pipeline is client-> decorator -> processor -> observer with client publication -> external partner, each input will go into a set of instances different from the previous and next one, and rejoin at the output who will queue and order them. You have parallel heavy work and sequential light result publication. Your simple output must be as fast as the sum of your parallel routes to minimize queueing. Ofc it s more complex, and I prefer 0 network hop myself, but I work on a large investment bank micro service system and we do not lock, and the component are both simple and complex enough that when one disappear, everything else waits or rebalances, and when it reappears it can catch up automatically, and go on. It consumes large amount of memory to keep a duplicated state in each component and persistence is not guaranteed to be on time (in fact, our persistence layer was 30 minutes behind by mid day, for years, until we dug into the 30yo sql)
    • b20000 4y ago
      so why do you need this to be distributed and why can you not use a monolithic server application, perhaps with background threads?
      • codebje 4y ago
        One reason come to mind: Conway's law. If you have a monolithic team a monolithic server is usually a pretty good solution to a problem. If you have multiple teams you're likely to wind up with an architecture that lets them work more independently, leading to separate release schedules. ... which perhaps just shifts the question to "why do you need multiple independent teams and not just use a monolithic development team?"
      • nimchimpsky 4y ago
• deleted 4y ago
  [deleted]
• 411111111111111 4y ago
  That's called distributed monolith. It's pretty much guaranteed to happen if the developers don't introduce a lot of redundancy while splitting up the services.
  • adam_arthur 4y ago
    If your services need to be chatty with eachother then the boundaries of the services are wrong. Hopefully by redundancies, you dont mean sharing data access logic