Hacker News new | ask | show | jobs
by benoau 658 days ago
As a starting point I'd go all-in on serverless because even though it's not necessarily the fastest response times or cheapest, it does let you completely ignore several sets of scaling challenges till the price matters. So I'd go serverless for spidering, indexing and user-facing APIs. UIs I'd go static HTML on a CDN.

For database, first I'd lean on plain file s3-like storage as much as possible for spidering and indexing data and try to keep the user-facing database under a couple hundred terabytes, I'd probably favor some bare metal at this point but that will fit on some "db as a service" providers.
1 comments
conradklnspl 657 days ago
While I agree that for user-facing APIs, serverless can both help handling load spikes and keep costs low, how would serverless help with spidering and indexing?

Spidering and indexing are processes that would most likely run continuously for any search engine like Google or Kagi. There is always data to update and new web pages being created.

Thus, they would benefit from dedicated servers from the get go for costs. Ahrefs posted an interesting article on this topic: https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-...

Then again, you could use serverless on your own dedicated servers to benefit from the advantages of both.

link
benoau 657 days ago
> how would serverless help with spidering and indexing?

Because these are tasks that lend themselves to massive concurrency and serverless makes that instantly possible. If you were going to put this on your own hardware that will be a pretty big project of its own.

How many months of dev time can you budget for rolling your own indexing/spidering infrastructure and getting that just right? How does that affect your launch date?

link