Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's plenty of server-side components to Figma that are substantially more complex and expensive than that of the typical website.

Multiplayer means that every file that are user loads is loaded onto a compute server and retained in-memory on that server, processing every mutation to the document. Figma documents can get quite large -- they can contain the design system of an entire organization, dozens of variations of a product feature, etc. This means the server cost scales per active session at a given time, a higher "number" than active requests.

In addition to multiplayer, Figma attempts to keep most other parts of the application real-time. If another user adds a file to a project, you will see it without refreshing the page. That's a simple example, but certain types of queries/mutation can get much more complex.

Figma is an enterprise app, and the data models needed to support complex use cases (permissions, etc) means that DB load is a real challenge.

While the DAU count of Figma might not be as high as other consumer apps, the amount of time those users spend in Figma is often substantially higher.

Those are some of the things that contribute to a high bill. While Figma is most known for the frontend editor, the infra work is plenty interesting too.






> Figma is an enterprise app, and the data models needed to support complex use cases (permissions, etc) means that DB load is a real challenge.

This, “permissions, etc”, isn't just an enterprise-scale problem, any multi-tenant system can and probably will hit it.

Working out who can access what can sound simple enough, but it gets rather less pleasant when the rules can be set with more complex ACLs¹ and because people can move around dynamically it is both potentially resource heavy to derive and difficult to cache² both safely and³ efficiently. It is natural to think “well, we can simplify the permissions model”, but you really can't when selling to different enterprises: many have their own idiosyncratic workflows, or local tweaks if using an “industry standard” workflow, and they will make a noise if your software to support them without extra tricks on their part.

We are at a much smaller scale⁴, in another industry, but this is an issue we have to be very careful about.

--------

[1] Is this person in a given group? Does that give or remove permission? Can they just access, or edit, add, …? also: different elements on the same screen could have very different ACLs to each other and at different times in a process

[2] missing changes for a time could cause significant issues if users are working on something commercially important or otherwise sensitive

[3] Safe is easy: don't cache at all. Efficient is easy: don't care about a bit of staleness and accept a bit of “eventual consistency”/“eventual correctness”. Achieving both takes a pile of resource even with a great design.

[4] We don't have to worry about consistently spreading data and processing over a set of DCs as our product has natural borders between tenants so splitting off into distinct DBs⁵ is an easy answer to some of the scale & efficiency issues.

[5] rather than needing everything in on “public” system because anyone can potentially want to share access with any other user.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: