4 ms·
> var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Yeah, no... you'll lose data for sure, you'll
by tsss 3y ago
> var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop();
Yeah, no... you'll lose data for sure, you'll have race conditions or no cooperative queuing between multiple instances of the application. This is exactly the kind of half-assery that people resort to when they say monoliths are so much less complex than microservices. A good monolith still requires all the same hard decisions about modularity, high-availability etc.
- smaudet 3y agoEh? Default queue implementations come with co-operating queuing out of the box. I suppose you could use some hand-rolled queue with no internal locking, but this is disingenuous. > you'll have race conditions or no cooperative queuing between multiple instances of the application. You're thinking micro-service again here. There's no need to have multiple "instances" at all. Any concurrency is handled internal to the application itself with use of e.g. fibers, threads, etc. A good argument to why monoliths have drawbacks can't be "well its not a microservice". :) > A good monolith still requires all the same hard decisions about modularity, high-availability etc. Never said it didn't. What it doesn't require is all the tech stack to support that over many instances, because there's one instance. A large majority of µServices is just re-implementing what your runtime gives you for free.
- erik_seaberg 3y agoSure, but even a monolith should store data on redundant hardware before launch, because commodity hardware isn’t completely reliable and neither are datacenters.