A few observations:

1. I saw the same headline - the article stated that there were record SEASON sales, not Black Friday sales. The headline did not match the content of the article. 2. Record revenue, not necessarily record units sold. To be expected with inflation. 3. Savvy online shoppers may be bundling purchases to reduce shipping costs. Waiting for a seasonal sale to buy holiday gifts as well as detergent, snacks and underwear may be quite prudent.

Finally, increased sales revenue does not necessarily equate to more jobs. It can, but by no means does it have to.

Consumers are needed for capitalism to work.

But not everyone needs to be a consumer. I could see the end result of all of this wealth consolidation being that the top 1% both own everything and are the only consumers. Rich people selling things to each other.

I once worked with a founder whose side business was building and selling yachts. Why yachts? If you asked him, he'd say because yacht buyers are the ones who have money.

Which is already happening. This is why stock buy-backs, IPO-less/private companies and private equity rule the future. This "wealth" will NOT come from government subsidies or UBI. It will stay where it is, with enough income doled out to the masses to keep the supply/demand economy chugging along.

Isn't it just a matter of having each consumer use their own offset? I mean if the queue table is sequentially or time-indexed, the consumer just provides a smaller/earlier key to accomplish the offset? (Maybe I'm missing something here?)

Correct, offsets and sharding aren't magic. And partitions in Kafka are user defined, just like they would be for postgresql.

Kafka allows you to have a consumer group… you can have multiple workers processing messages in parallel, and if they all use the same group id, the messages will be sharded across all the workers using that key… so each message will only be handled by one worker using that key, and every message will be given to exactly one worker (with all the usual caveats of guaranteed-processed-exactly-once queues). Other consumers can use different group keys and they will also get every single message exactly once.

So if you want an individual offset, then yes, the consumer could just maintain their own… however, if you want a group’s offset, you have to do something else.

Yes.

Is a queuing system baked into Postgres? Or there client libraries that make it look like one?

And do these abstractions allow for arbitrarily moving the offset for each consumer independently?

If you're writing your own queuing system using pg for persistence obviously you can architect it however you want.

So, rather than Big Brother being government-imposed monitoring paid for by all taxpayers, the concerned citizenry is flipping the bill for the devices, network connectivity and electricity. Fascinating.

always, flock just charges local governments and then charges the police too to get access. They get us coming and going, and yet most crimes and murders go unsolved still. If a cop can track his Ex through hundreds of cams, why aren't the solve rates better? (Its not about crime)

Tax payers and citizenry are largely the same. It's not really flipping the bill.

Yep, it's like we speedran 1984 but made it a startup

That's just capitalism vs socialism. In communist countries, the state provides the surveillance. In capitalist America, the consumers pay for state surveillance.

> (Technically speaking, if 100 people load the same page at the same time and the cache isn’t populated yet, then we’ll end up sending 100 queries to the database which isn’t amazing, but let’s just pretend we didn’t hear that.)

Isn't their tech to address that, like golang's "singleflight"?

Agreed. Isn't this precisely why key statistics (table statistics) are maintained in many DB systems? Essentially, always "push down" the predicate with the worst statistics and always execute (early) the predicates with high selectivity.

I'd be very surprised if virtually every RDBMS doesn't do this already.

Interesting. But this uses mattn's go-sqlite3 package, which is CGO.

Is this a normal/expected requirement in modern GO?

Virtual tables are fully supported by my CGO free driver: https://pkg.go.dev/github.com/ncruces/go-sqlite3

You can have a look at a bunch of examples in my extensions folder: https://github.com/ncruces/go-sqlite3/tree/main/ext

PS: The mattn CGO driver actually doesn't seem to support wrapping the xBegin/xSync/xRollback/xCommit methods. Mine actually does, although it's largely untested, as I haven't needed this yet.

We use mattn's go-sqlite3 in our SaaS product. It's not ideal from a toolchain perspective (i.e. cross compiling becomes a little annoying, especially with multi-arch Docker images) but once you get across that hurdle, we haven't run into any major problems with cgo.

I bet SQLite3 builds on more platforms than Go.

It’s not about the build platform, it’s about the execution platform and not having to have a toolchain for every platform. This is especially relevant in the embedded space.

There is no pure Go implementation of SQLite3 so...

There's at least…

https://modernc.org/sqlite which preprocesses and transpiles the amalgamation from C to Go.

https://github.com/ncruces/go-sqlite3 which runs a Wasm build of SQLite through a pure Go Wasm runtime.

Both, but much more chat-focused. I've created 20 or so images for various little home projects.

I guess that. I have a paid account ($20/month flavor) and have the link saved. I just asked it to create an image of a landscape and it popped up this blocking request to use pyxl.pro

I found a work-around (see other comment)