undefined | Better HN

0 pointsrco87869y ago0 comments

> If you end up with enough traffic that it actually becomes a problem, it would have been a problem anyway because you'd be running a lot of servers with persistent connections in a more traditional model.

I think this is the part I disagree with. DB connection pools are much, much smaller than than the total # of functions that touch a database in any reasonably complex application.

Yes, scale is always an issue, but it seems to me that in this serverless world where you have 1 connection per function you run into scale issues a lot(order of magnitude?) faster than the "traditional" way.

> a good abstraction means only one or maybe two functions actually talks to the database

In a serverless world, does this mean you would run a handful of functions with DB connections, and other functions would proxy db requests through them? I can see that working ok I suppose.

0 comments

mcherm9y ago

For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool.

I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worries me.

jedberg9y ago

You could build the transaction support into the database service. Then when you need to write multiple things, you put them into a queue as a single work unit, and let your abstraction deal with taking the work unit off the queue and putting into the database in a single transaction.

This has the added effect of making your system more reliable because you'll be using queues and you have a shorter window when a process can die and hang a db connection that is trying to roll back.

mcherm9y ago

You certainly COULD (and if I were designing it I would have either done that or allowed callers to request a transaction in which case a connection is temporarily reserved for that client and a token returned which can be used to continue the transaction). But the people designing it DIDN'T do either. Which is part of why I question their design.

jedberg9y ago

I wouldn't call it so much proxying the DB requests through it as all the other functions do business logic, only one or two actually marshal data into and out of the datastore.

So yeah it's kind of like a proxy, but think of a monolithic application. Do you make it so every object in your application talks to the DB, or do you have a DB object, which handles the connection pooling and all of that other stuff? If you have a DB object, that becomes your DB function, and all the other functions talk to it for getting and writing data.

j / k navigate · click thread line to collapse

0 pointsrco87869y ago0 comments

I think this is the part I disagree with. DB connection pools are much, much smaller than than the total # of functions that touch a database in any reasonably complex application.

> a good abstraction means only one or maybe two functions actually talks to the database

In a serverless world, does this mean you would run a handful of functions with DB connections, and other functions would proxy db requests through them? I can see that working ok I suppose.

0 comments

mcherm9y ago

For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool.

jedberg9y ago

This has the added effect of making your system more reliable because you'll be using queues and you have a shorter window when a process can die and hang a db connection that is trying to roll back.

mcherm9y ago

jedberg9y ago

I wouldn't call it so much proxying the DB requests through it as all the other functions do business logic, only one or two actually marshal data into and out of the datastore.

j / k navigate · click thread line to collapse