mattheath

You're welcome! In our case linkerd is critical to this, as we've offloaded load balancing, circuit breaking, and retry policies etc to linkerd. If we hadn't then we would need to implement this functionality in multiple languages (though we mainly use go) and keep these in sync as we developed our platform, which from my experience is quite difficult. Using linkerd largely removes this from us, meaning we have a well tested method of inter-service RPCs, and we get free feature development ;) For async processing we're using Kafka, which powers the majority of our event sourced architecture.

We store the vast majority of our data in Cassandra, which gives us tuneable consistency and high availability given its master-less architecture. Those properties suit the rest of our architecture perfectly, though there are of course trade offs involved. Each service then has its own keyspace and is unable to access the data of other services.

Hi, author here. Happy to answer any questions!

TL;DR Yes, but as someone else mentioned, the real question isn't if Go is suitable for Fintech, but if it's suitable for your team and the specific problem you are trying to solve.

I work for a startup called Mondo - we're building a full-stack bank and currently it's almost entirely in Go. However, this is a function of our architecture - we provide an API which our apps and frontend (some using react) communicate with. Behind this API are >100 microservices which comprise our application, and Go works exceptionally well for this type of architecture, as it excels at network services.

In your case it seems that you're building a web application, so Rails is going to be easier to build out a prototype, hire for, and has taken care of a huge number of your concerns already at a framework level. There is of course nothing stopping you from splitting out functionality later into smaller Go based applications, but I doubt at this point speed of code execution should really be a concern - if you're building a new company you need speed of product execution, no?

Regarding functionality, Go will do everything you're asking for: - CSRF can be handled with middlewares like Gorilla's CSRF package: http://www.gorillatoolkit.org/pkg/csrf - Postgres with the standard database package, or other packages on top - Third party APIs such as Stripe/Dwolla/Braintree will be fine - If you're looking at integrating with other (older) parts of the global financial network (eg. is there an OFAC checking service with a nice API?), then you may find other languages would be easier for these tasks. In our case we may end up abstracting some of these with services in other languages that already have libraries to interact with these systems, and then providing a nice internal API our services can interact with.

So, Rails has a huge number of framework level features which may help you move faster as you develop your product. But, yes, Go is perfect for Fintech applications, we're building a bank and love it.

That was me ;) Atom's great until you save and goimports locks up the whole UI. Think that is the protobuf interface used by the client and server in our tracing tool, so handy having them all open! https://github.com/mondough/phosphor

I would disagree with this - it's a very broad statement. While building frameworks often encourages developers to abstract to the nth degree and add far more flexibility than is required, if you have specific requirements what's the problem?

We built a microservice architecture in Go at Hailo which runs approx 170 services. Abstracting core functionality into a 'framework' allowed developers to build and deploy services extremely quickly, and let the platform team get on with adding and improving core platform functionality, such as monitoring, instrumentation, tracing, provisioning, configuration etc etc.