# Finagle Published articles for Finagle. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The End of the Public API Strangler DevFeed: [The End of the Public API Strangler]() Original publisher: [Read original article]() Published: 2022-03-14T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [BFF](), [Microservice](), [Finagle](), [Scala](), [Architecture & Design](), [Remote Procedure Call (RPC)](), [Rails](), [Ruby]() Tags: [api](), [architecture](), [bff](), [engineering](), [finagle](), [microservices](), [rpc](), [ruby](), [scala]() ### AI overview SoundCloud describes an eight-year migration of its public API from a monolithic Ruby on Rails application to a BFF using the Strangler pattern. The approach introduced a Scala service built with Finagle to proxy and augment API responses while functionality moved across microservices. ### Source excerpt This is the story of how we used the Strangler pattern to migrate our public API from a monolithic codebase to a fully fledged BFF over the... ## Announcing Twinagle: Twirp and Protobuf for Finagle DevFeed: [Announcing Twinagle: Twirp and Protobuf for Finagle]() Original publisher: [Read original article]() Published: 2020-06-12T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Twirp](), [Finagle](), [Remote Procedure Call (RPC)](), [Go Language](), [Microservices](), [Go](), [HTTP](), [JSON](), [API](), [Back end](), [Architecture & Design]() Tags: [announcements](), [backend](), [engineering](), [finagle](), [go](), [http](), [json](), [microservices](), [open-source](), [performance](), [rest](), [rpc](), [scala](), [twirp]() ### AI overview SoundCloud announces Twinagle, an open source implementation of the Twirp protocol for Scala/Finagle. The article explains how Twirp and Protocol Buffers can replace more flexible HTTP and JSON conventions with standardized RPC contracts, reducing API inconsistencies and potentially improving performance and development speed. ### Source excerpt A previous post on this blog ended with the following paragraph: "We might also replace JSON with a more efficient serialization protocol... ## Tracing High Volume Services DevFeed: [Tracing High Volume Services]() Original publisher: [Read original article]() Author: Anton Kropp was a Software Engineer Published: 2017-09-26T12:11:36Z Content type: article Language: en Sources: [Curalate]() Topics: [tracing](), [debugging](), [Logging and metrics](), [Finagle](), [HTTP]() Tags: [debugging](), [devops](), [finagle](), [http](), [logging](), [logging-and-metrics](), [okhttp](), [scala](), [services](), [soa](), [tracing]() ### AI overview The article explains how to trace requests across a high-volume service ecosystem by propagating a trace identifier through service calls and including it in logs. It describes Curalate's use of Finagle and custom OkHttp interceptors to place the identifier in HTTP headers, then reuse it in logging contexts and structured JSON logs. ### Source excerpt We like to think that building a service ecosystem is like stacking building blocks. You start with a function in your code. That function is hosted in a class. That class in a service. That service is hosted in a cluster. That cluster in a region. That region in a data center, etc. At each level there's a myriad of challenges. From the start, developers tend to use things like logging and metrics to debug their systems, but a certain class of problems crops up when you need to debug across services. From a debugging perspective, you'd like to have a higher projection of the view of the system: a linearized view of what requests are doing. I.e. You want to be able to see that service A called service B and service C called service D at the granularity of single requests. Cross Service Logging The simplest solution to this is to require that every call from service to service comes with some sort of trace identifier. Incoming requests into the system, either from public API's or client side requests, or even from async daemon invoked timers/schedules/etc generates a trace. This trace then gets propagated through the entire system. If you use this trace in all your log statements you can now correlate cross service calls. How is this accomplished at Curalate? For the most part we use Finagle based services and the Twitter ecosystem has done a good job of providing the concept of a thread local TraceId and automatically propagating it to all other twitter-* components (yet another reason we like Finatra!). All of our service clients automatically pull this thread local trace id out and populate a known HTTP header field that services then pick up and re-assume. For Finagle based clients this is auto-magick'd for you. For other clients that we use, like OkHttp, we had to add custom interceptors that pulled the trace from the thread local and set it on the request. Here is an example of the header being sent automatically as part of Zipkin based headers (which we re-use ## Inside a SoundCloud Microservice DevFeed: [Inside a SoundCloud Microservice]() Original publisher: [Read original article]() Published: 2017-07-28T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Microservice](), [Microservices](), [Architecture & Design](), [Back end](), [Finagle](), [Scala](), [API](), [JSON](), [Network](), [RSS Feed](), [telemetry](), [Messaging]() Tags: [api](), [architecture](), [backend](), [configuration](), [finagle](), [functional-programming](), [json](), [messaging](), [microservices](), [microservices-architecture](), [network](), [rss](), [scala](), [telemetry]() ### AI overview The article describes SoundCloud's transition from a monolithic backend to independently built and deployed microservices. It explains how the Creators Team implements services in Scala with Finagle, shared libraries, APIs, JSON or Thrift communication, configuration injection, telemetry, and service-to-service request aggregation. ### Source excerpt If you're a regular visitor to this blog, you might be aware that we have been transitioning to a microservices based architecture over the past four to five years, as we have shared insights into the process and the related challenges on multiple occasions. To recap, adopting a microservices architecture has allowed us to regain team autonomy by breaking up our monolithic backend into dozens of decoupled services, each encapsulating a well defined portion of our product domain. Every service is built and deployed individually, communicating with other services over the network via light-weight data interchange formats such as JSON or Thrift. What we haven't touched on so far is how a microservice at SoundCloud looks backstage. ## Lessons in resilience at SoundCloud DevFeed: [Lessons in resilience at SoundCloud]() Original publisher: [Read original article]() Published: 2016-12-07T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Resilience](), [Remote Procedure Call (RPC)](), [client](), [Microservice](), [Architecture & Design](), [systems](), [Network]() Tags: [architecture](), [finagle](), [http](), [microservices](), [network](), [resilience](), [rpc](), [systems]() ### AI overview This article discusses resilience in distributed services at SoundCloud, focusing on RPC at scale. It explains the circuit breaker pattern and its combination with client-side load balancing, including how service health, partial failures, and high load affect request handling. ### Source excerpt Building and operating services distributed across a network is hard. Failures are inevitable. The way forward is having resiliency as a key part of design decisions. This post talks about two key aspects of resiliency when doing RPC at scale - the circuit breaker pattern, and its power combined with client-side load balancing. ## Microservices and the monolith DevFeed: [Microservices and the monolith]() Original publisher: [Read original article]() Published: 2016-08-26T00:00:00Z Content type: opinion Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Architecture & Design](), [Microservice](), [microservices architecture](), [HTTP](), [Prometheus](), [Docker](), [Kubernetes](), [Finagle](), [telemetry](), [Testing]() Tags: [architecture](), [docker](), [finagle](), [http](), [kubernetes](), [microservices](), [microservices-architecture](), [monolithic-architecture](), [prometheus](), [telemetry](), [testing]() ### AI overview SoundCloud reviews its migration from a monolithic architecture to microservices and evaluates the strategy needed to decommission the monolith. The article reports that internal tools and libraries improved service creation and engineering productivity, while extraction projects remained difficult because they took months and depended on multiple teams. ### Source excerpt In a previous series of blog posts, we covered our decision to move away from a monolithic architecture, replacing it with microservices, interacting synchronously with each other over HTTP, and asynchronously using events. In this post, we review our progress toward this goal, and talk about the conditions and strategy required to decommission our monolith. ## Synchronous communication for microservices: current status and learnings DevFeed: [Synchronous communication for microservices: current status and learnings]() Original publisher: [Read original article]() Published: 2016-07-27T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Microservice](), [Architecture & Design](), [Finagle](), [Remote Procedure Call (RPC)](), [Scala](), [HTTP](), [JSON](), [Netty](), [Scalability](), [Prometheus](), [MySQL](), [Routing (disambiguation)]() Tags: [architecture](), [blog-post](), [finagle](), [framework](), [http](), [json](), [library](), [microservices](), [microservices-architecture](), [mysql](), [programming](), [prometheus](), [rpc](), [scala](), [scalability]() ### AI overview This article describes SoundCloud's use of synchronous request-response communication in a microservices architecture. It discusses Finagle and Scala-based services, the internal jvmkit library, non-blocking I/O, service discovery, routing, logging, Prometheus integration, and the use of HTTP/1.1 with JSON. It also explains the interoperability and debugging benefits of HTTP and JSON, along with their greater overhead compared with more optimized protocols. ### Source excerpt Since we started breaking our monolith and introduced a microservices architecture we rely a lot on synchronous request-response style communication. In this blog post we'll go over our current status and some of the lessons we learned. ## Building Products at SoundCloud--Part III: Microservices in Scala and Finagle DevFeed: [Building Products at SoundCloud--Part III: Microservices in Scala and Finagle]() Original publisher: [Read original article]() Published: 2014-06-13T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Finagle](), [Node.js]() Tags: [architecture](), [clojure](), [concurrency](), [finagle](), [http](), [microservices](), [node-js](), [resilience](), [rpc](), [ruby](), [scala]() ### AI overview SoundCloud describes its move from a Ruby on Rails monolith to microservices, consolidation around JVM languages, and evaluation of Netty, Netflix, and Finagle stacks for RPC, resilience, and concurrency. ### Source excerpt In the first two parts of this series, we talked about how SoundCloud started breaking away from a monolithic Ruby on Rails application into... ## Building Products at SoundCloud--Part II: Breaking the Monolith DevFeed: [Building Products at SoundCloud--Part II: Breaking the Monolith]() Original publisher: [Read original article]() Published: 2014-06-12T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Microservices](), [Architecture & Design](), [Rails](), [Scala](), [Clojure]() Tags: [activerecord](), [architecture](), [finagle](), [legacy-application](), [microservices](), [rails](), [refactor](), [ruby](), [scala]() ### AI overview SoundCloud describes extracting a bounded context for user-to-user messages from its legacy monolithic Rails application, Mothership, into a separate microservice. The process involved refactoring ActiveRecord-coupled code around a seam, replacing the implementation with a service call, and gradually running the microservice alongside the legacy code to avoid a disruptive big-bang refactoring. The article also explains why Mothership's application database should not serve as the integration point. ### Source excerpt In the previous post, we talked about how we enabled our teams to build microservices in Scala, Clojure, and JRuby without coupling them... ## Building Products at SoundCloud --Part I: Dealing with the Monolith DevFeed: [Building Products at SoundCloud --Part I: Dealing with the Monolith]() Original publisher: [Read original article]() Published: 2014-06-11T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [web applications]() Tags: [api](), [architecture](), [finagle](), [microservices](), [ruby](), [scala](), [scalability]() ### AI overview SoundCloud describes moving from a monolithic Ruby on Rails system toward microservices to address scalability problems. ### Source excerpt Most of SoundCloud's products are written in Scala, Clojure, or JRuby. This wasn't always the case. Like other start-ups, SoundCloud was...