5 posts · 3 companies · newest first
This is part 8 in a series of posts on writing concurrent network servers. In this part, we'll switch to Go and see how it tackles the challenges described earlier in the series. All posts in the series: Part 1 - Introduction Part 2 - Threads Part 3 - Event-driven Part 4 - libuv …
When it comes to the communication between microservices, there are 2 possible extremes:All-sync: whenever a service needs data from another service, it fetches it via a synchronous API call (REST, gRPC, GraphQL). Service calls service calls service… which tends to evolve into layers of APIs, where each layer has dependencies on the next.All-async: no sync calls between services, all communication is event-driven or in the form of data replication. This tends to form silos: independent services that are fed all the data they need by an async mechanism and can function independently of any…
This is an introduction to how we’ve implemented microservices at a mid-size scale-up called Jobteaser, with a mix of Go and Ruby service chassis, gRPC APIs and data replication via Kafka.Foundation: The service chassisBack in early 2019, when Jobteaser decided to get serious about breaking up its decade-old Rails monolith into microservices, we assembled a Foundation team that started working on an in-house service chassis.It was soberly coined service and came in two flavours: the rb-service framework in Ruby and the go-service framework in Go. Four years later, they still form the…
I’m a backend developer who worked extensively writing code in Golang before joining SoundCloud. SoundCloud mostly uses Scala for its…
In a previous blog post, we explained how we built an internal pull-based exception monitoring service called Periskop — which is heavily…