7 ms·
I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "u
by Toine 5y ago
I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "user" microservice, with its User class and repository, 100 LOC, a "message" microservice with 80, etc. Aggressively arguing the superiority of their monster. Of course the services all shared the same db, completely missing the actual benefit of microservices. And every service was completey coupled to others and could not run on its own.
How do you fix that ?
- davidw 5y ago> How do you fix that? You run away as fast as you can is what you do.
- keithnz 5y agoeventually they are just going to invent an actor framework
- anonymoushn 5y agoThe user service team told us we were querying them too much, so we just stored usernames in addition to user IDs to avoid querying them, then later documents would have the wrong username on them if the user changed their username. One perspective is that we were negligent and caused a bug, but another possible perspective is that maybe the user service team should have caching instead of every other team building their own caching for the user service.
- marsdepinski 5y agoThey should send a cache-control header in the response or 304 Not-modified when queried with not-modified-since. The calling service should always be the one responsible for caching to save the network round-trip. And if you're going to duplicate data like usernames, get a message channel setup to propagate the changes into the system cloning data.