People are excited to watch card pack openings, more content creators start making that content since it's popular, demand for old sealed product goes up driving price increases which also makes it more exciting, not to mention the increase in content introduces a broader audience, and then again more people interested leads to more content and demand and price increases.
It's a feedback loop, hard to say exactly what got it going, how big it can get, and what happens when it slows or stops, but for now you can enjoy the mania.
Matt Levine might credit this to his "boredom markets hypothesis" during the pandemic. If you can't go out to a bar or a movie or a casino, then speculating on stocks or crypto or Pokemon cards is more fun compared to the now more limited options you have available, so more people will do that. https://archive.is/X8qY6
> 1. Query the database to find all dormant accounts with a balance, which haven't been charged the fee this month.
> 2. Charge each of these accounts a fee
> 3. Setup a cron job to run this every hour
Note that if this job ever runs successfully, but takes more than an hour, you will double-count. Can easily happen if the box running these crons is overloaded. One fix is to automatically halt the job after 55 minutes, another would be to have the middle step be impotent, for each user you're doing the process on, ensure (ideally in a threadsafe manner) that they need the operation to be done still.
The article didn't really go into the details of the implementation but my mental image was basically your second proposal: the deduction of the fee should happen in the same database transaction as the updating of a "fee-last-charged" timestamp, relying on the database for thread safety and allowing the cron job itself to be stateless (and inherently protected against simultaneous execution of multiple instances of itself).
If some rogue deploy script creates fifty of the cron job, and weirder things happen every day, one of those could be checking the stale state during the transaction of another one. A classic data race.
Eliminating this problem is left as an exercise for the interested reader...
The way to fix that is to remove state altogether.
1. Balance is not a simple variable, but the sum of all credits and debits to an account
2. A fee is a charge record in your database
3. This fee has a database constraint that you can have only one record per month
Now you can run the script that charges dormant fees as often as you want.
This is exactly the right approach, and the easiest way to implement idempotency in many realistic systems. Instead of thinking about idempotency in verbs - "perform action iff action has not yet been performed" - think about it in nouns - "create a piece of data whose key is the tuple of its inputs".
Practically speaking, this narrows your "transaction window" significantly - instead of:
1. Begin transaction
2. Check to see if work has already been done
3. Do work
4. Persist work
5. Commit
With a potentially long transaction spanning from 1-5, you do this:
1. Do work
2. Persist work to key / table with uniqueness constraint
3. On conflict, do nothing (looks like you already did the work before)
Of course if "Do work" is very expensive, you can bring back in "Check to see if work has already been done" as an optimization, but for many simple CRUD examples, it's actually /cheaper/ to learn that the work has already been done via the conflict check failing than via an explicit pre-flight check.
I believe coinbase holds a lot of crypto - in the robinhood analogy, coinbase is their own clearing house. So they don't have to post collateral to themselves, but if crypto movement was all in one direction on a given day, they might rely on the market instead of the liquidity they themselves provide. Maybe in such a scenario they would be clever enough to NOT resolve all the trades instantly.
Got it, so in general, they are _actually_ fronting you the asset (although you can't take it out of their control until you've paid up), as opposed to an IOU.
Yeah, they already have the asset when you click buy. On "consumer", the blue one, when you click buy it literally does a direct market order off of Coinbase Pro to purchase the asset, and since it's on Pro they already have the crypto on platform.
Just tested https://gallery.flutter.dev/#/crane in Chrome and Safari on Mac and if I go to another tab and then back to the fly tab it just shows a gray screen. Does not inspire confidence.
I think there's an idea out there that a this is a life plan that will succeed:
- Go to college
- Take loans to pay for it if you need to
- Get a degree in something that interests you
- Get a career in that field
- Make money, buy a house, have a family
It seems that this vision is becoming less true than it used to be or has more caveats (try to save money on the schools you attend, pick a degree that pays decently and that there are lots of available jobs in, find a cheaper market to buy your house in).
I think the life planning of people entering college has taken quite a while to catch up as this shift has occurred. Although it does seem to be taking hold now as more and more people discover that they really struggle to get out from under student loan debt, can't get jobs in their relevant fields, or find they can't buy a home.
I think it's good to see data like this put together, and more crucially to present some realistic perspectives to kids about what possible paths they might take in life and what the risks/rewards of those plans might look like.
That was the life plan the boomers took for granted, except the college part was largely optional. Now it's our fault that we don't live the same magical charmed lives they did.
