In particular, as to their original problem, the shared library seems to be the main source of pain and that isn't technically solved by a monolith, along with not following the basic rule of services "put together first, split later".
I feel prematurely splitting services like that is bound to have issues unless they have 100 developers for 100 services.
The claim of "1 superstar" is misleading too, this service doesn't include the logic for their API, Admin, Billing, User storage etc etc, it's still a service, one of a few that make up Segment in totality.
We're revolutionising healthcare with medication delivery and management and we’re looking for Golang/Node/K8S devs to work on services based architecture and cloud infra here at Echo.co.uk! We’re based in London and love Kubernetes, Prometheus, Go, GraphQL, Istio and good Coffee. We have just raised a series A round of 7m funding and will be integrating with the NHS soon along with a larger roadmap.
Email alex.barlow[at]echo.co.uk
ABOUT US: We’re looking for Golang devs to work on (micro)services and cloud infra here at Echo.co.uk!
We’re based in London and love Kubernetes, Prometheus, Go, GraphQL and GCP and good Coffee. We have just raised a series A round of funding and will be integrating with the NHS soon.
Kubernetes, Prometheus, Go, GraphQL, GCP, Node, Docker are all good knowledge areas to have. But generalists are welcome and new Go coders are welcome too!
Please contact alex.barlow@echo.co.uk https://www.echo.co.uk/careers
Could you expand on the techniques you use to implement idempotency in your workers/queues and in your rpcs?
I have seen a mix of doing nothing if there is nothing to do, locking, using a idempotency key and so on. But I am always curious to see what others do.