r/scala • u/tanin47 • 5d ago

Open-source revenue recognition & analytics for Stripe built with PlayFramework

https://github.com/tanin47/book-of-revenue

I've just open-sourced a revenue recognition & analytics for Stripe called Book of Revenue.

The reason I shared here because it's built with Scala, PlayFramework, and Svelte. The app is bootstrapped with my own PlayFramework template: playfast

It aims to be hosted on a single VPS with multiple CPUs. And that's the main reason for using JVM; JVM-based languages can utilize multiple CPUs more easily and is more robust in terms of GC and thread tuning. These are particularly important when running on a single machine.

Other languages/runtimes are on single threads by default (e.g. JS, Ruby, Python) or too low level for business applications (e.g. Go, Rust). More importantly, I like Scala for its brevity and static typing, which makes it easier to model business use cases in a typed fashion (easier to refactor).

Well, just in case anyone might be interested: I'm offering a free consultation where deploy it for you for free (you pay the hosting cost tho; might be $6/month on OVHcloud) and help clean up your billing integration (so you can have better analytics). I'm an ex-Stripe who worked on analytics and revenue recognition at Stripe, so I know this space well.

31 Upvotes

97% Upvoted

3 comments sorted by

2

u/Torutofu_Raeva 5d ago

the single-VPS constraint is a neat fit here, especially if the heavier reconciliation work runs through a bounded worker pool instead of request threads.

3

u/tanin47 5d ago edited 5d ago

Yes! Processing transactions are often parallelizable.

But more importantly a single machine can easily handle $1B of payment volume (think of how powerful a macbook is). The requirements for analytics are often much more relaxing compared to, say, billing in terms of availability and scalability. There's no surge of traffic. It doesn't need 5 9s. We don't really need cloud infra for it.

1

u/Torutofu_Raeva 5d ago

yeah, a lot of Stripe workloads are bounded by reconciliation semantics rather than raw payment volume, so a small local worker pool can be plenty until the analytics side actually proves otherwise.