Hacker News new | ask | show | jobs
by ceejayoz 968 days ago
We use Lambda (via Laravel Vapor; https://vapor.laravel.com/) for a big analytics batch processing job every night; it spawns hundreds of thousands of individual jobs that make various API calls, but only for a few minutes. For the rest of the day it's doing very little.

I'd imagine a bank has quite a few of these sorts of bursty bash processing needs; ACHes, end-of-day reconciliation, etc.

4 comments

At my last job, we had an architecture that ran hundreds of thousands of individual jobs with internal API calls for nightly account updates and reporting work, and it was a major battle to finally get it replaced with some simple SQL scripts which ran orders of magnitude faster while being a lot more reliable.

As I understand it, banking commonly uses JVM where you can easily do async or multithreaded processing and task scheduling, so lambda doesn't offer much over ECS, and the timeout could be a real killer.

What's your experience with Vapor? We played around with it and thought about switching from Forge, but it was too complicated for our codebase. I love the idea though.

How expensive our your cloud costs? CI/CD pretty good?

Overall quite good. We use their Docker container support (to get ffmpeg, mostly) and it's been pretty smooth running throughout. I'd previously used a lot of Heroku so the habits developed there paid off in our codebase for Vapor; only a few tweaks were really needed.

Cost-wise we're pretty bursty, so it's saved us quite a bit. Lambda runtime is money, so a little bit of performance optimization can go a long way. CI we run through Github Actions; an environment secret plus `vapor deploy` and it's on its way up after a successful run.

Wasn't a fan of Forge; for that style of things I'd use Ploi nowadays.

Lambdas are amazing at clearing queues.

You can have a single queue gathering workloads and then have Lambda functions grab a bunch of tasks, handle them, grab more etc. until the max runtime is met and they're automatically rebooted.

It's also pretty trivial to add more processing capacity when the queue goes over a specified limit just by allowing for more concurrent Lambdas.

And when there's nothing to process, you've got one idling Lambda doing nothing and costing nothing.

I did some fintech work as a junior / kinda non junior dev. This is correct. I think 90% of the work was taking pictures of checks, and setting up batch jobs. all batch: - money movement (between accounts) - transfers - wires - etc.

even the 'non' batch things were done in batch (even if it's do now, and only 1).