Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We reduced the cost of building Mastodon at Twitter-scale by 100x

blog.redplanetlabs.com

Post reply on HN
Print view View original

51–60 of 376 posts

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#51

Post by yid »

nathanmarz wrote: post #33
trollied wrote: post #16

> We spent nine person-months building our scalable Mastodon instance. + the time spent creating Rama, the platform that enables it. Very dishonest leaving that out.

You're missing the point. Rama is a generic platform that provides a new baseline for how expensive it is to build applications at scale. There's nothing about Rama specific to social networks. What we're showing is that Rama creates a new era in software engineering where the cost of building applications at scale is radically reduced. With Rama, anyone embarking on a new application today has a radically different…

> What we're showing is that Rama creates a new era in software engineering where the cost of building applications at scale is radically reduced.

Bold of you to come to HN with the breathless hyperbolic marketing fluff that may work on Twitter...

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#52

Post by goostavos »

_dwt wrote: post #14

Hmmm, "Rama is programmed entirely with a Java API – no custom languages or DSLs" according to the landing page, but this sure looks like an embedded DSL for dataflow graphs to me - Expr and Ops everywhere. Odd angle to take.

Odd thing to split hairs over.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#53

Post by nathanmarz »

softwaredoug wrote: post #42

It’s a massive ask, even if the platform was 100x better, for all developers to give up every programming language and database they’ve ever used to depend on a startups closed source platform for all functionality. It’s hard enough trusting Google or Amazons cloud offerings won’t change. It seems that’s what they’re proposing right? What am I missing?

We're actually not asking anyone to give up anything. First off, it has a simple integration API (which you'll be able to see the details of next week) that allows it to seamlessly integrate with any other backend tool (databases, monitoring systems, queues, etc.). So Rama can be incrementally introduced into any existing architecture.

Second, Rama has a pure Java API and is not a bespoke language. So no new language needs to be learned.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#55

Post by jedberg »

Pxtl wrote: post #25

I've seen many people describe frameworks like this - you know, first you have the slow back-end event-driven master database that you don't query live against, then you've got eventual-consistency flows against the various data-warehouses and data-stores and partitioned sharded databases in useful query-friendly layouts that you actually read live from... and I never see it clearly explained: how do you read a chang…

The short answer is write-through cache.

You write the update directly to the cache closest to the user and into the eventually consistent queue.

We did this at reddit. When you make a comment the HTML is rendered and put straight into the cache, and the raw text is put into the queue to go into the database. Same with votes. I suspect they do this client side now, which is now the closest cache to the user, but back then it was the server cache.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#56

Post by titanomachy »

ciconia wrote: post #30
LeifCarrotson wrote: post #12

> How is it possible that we’ve reduced the cost of building scalable applications by multiple orders of magnitude? > You can begin to understand this by starting with a simple observation: you can describe Mastodon (or Twitter, Reddit, Slack, Gmail, Uber, etc.) in total detail in a matter of hours. It has profiles, follows, timelines, statuses, replies, boosts, hashtags, search, follow suggestions, and so on. It doe…

> I'm honestly shocked that the technical implementation of a simplified, coherent platform took a full 9 person-months. To be fair they developed this whole new platform to build this app with. I guess that's where the effort went.

Not exactly:

> Our implementation is built on top of a new platform called Rama that we at Red Planet Labs have developed over the past 10 years.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#57

Post by hot_gril »

jokethrowaway wrote: post #40
Pxtl wrote: post #25

I've seen many people describe frameworks like this - you know, first you have the slow back-end event-driven master database that you don't query live against, then you've got eventual-consistency flows against the various data-warehouses and data-stores and partitioned sharded databases in useful query-friendly layouts that you actually read live from... and I never see it clearly explained: how do you read a chang…

You can hack it and optimistically render the data you know about because your client created it - on the frontend, at no additional cost.

This is usually what I do. Don't even want to wait for an HTTP roundtrip for some of these, e.g. "liking" a post should fill in the heart icon or whatever instantly.

One famous example of this going to far: Mac Mail app used to play a whoosh sound when your email is actually sent. They changed it to whoosh instantly no matter what. Given how often an email might fail to send or get delayed, this meant an actually useful indication of "great, your thing was sent, you can close your laptop now" was rendered useless.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#58

Post by gfodor »

Something I'm immediately thinking about with this is change management and inertia at the early stages of a new, underdefined project. Less code is great, the big question is how such a system compares to the usual hack-and-slash method of getting a v1 up and running as you search for PMF from the perspectives of ops, cost, data migrations, rapid deployments, and so on. Presumably, the idea here is to start from the beginning with Rama, skipping over the usual "monolith fetches from RDBMS" happy paths, even for your basic prototype, this way you don't slip into a situation like Twitter did where that grew slowly into an unscalable monstrosity requiring a rewrite. So an article focused on the "easy" part that's required in the beginning of rapid change, as much as it's not as important as the "simple" part that shines later at scale, seems useful.

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#59

Post by DoesntMatter22 »

phillipcarter wrote: post #34

In the year of our lord 2023, people are still launching immature products with "we built a clone of a tiny subset of Twitter" as their use case? Come on. Twitter is huge because they have to support a huge number of use cases. Using this proprietary framework won't magically make complex use cases go away.

"We recreated a service from 2007 and it's so much faster!"

Re: We reduced the cost of building Mastodon at Twitter-scale by 100x

#60

Post by Kiro »

dang wrote: post #41
Kiro wrote: post #31

Earlier quoted context omitted.

That's not the title of the article and also not what the article says. I would be really pissed if you editorialized the title of my article like that.

I'm happy to correct it if anyone suggests a better one. The intention is to find a neutral title that accurately reflects what the article itself is saying. We've learned that when an article's original title generates complaints like https://news.ycombinator.com/item?id=37137317 , the thread is likely to get derailed by shallow arguing about the title. It's in both the author's interest and the community's for us t…

Alright, sounds reasonable. I think the problem here is that the author specifically says (in a sibling comment) that the point is not Mastodon and now it's in the title. Maybe they're fine with it though.
Post reply on HN