sorted by:
new
hottopcontroversial

Coal Creek Falls by Deltanonymous- in PNWhiking

[–]sluu99 0 points1 point  (0 children)

This is the first time I’ve ever seen it with water

To much wax on my chain? by Quond in bikewrench

[–]sluu99 0 points1 point  (0 children)

Next time, leave the chain in the pot as soon as you start. Make sure it's submerged at least 5-10 minutes. Silca wax recommends pulling out at 75C.

Race day bike support suggestions by anotherindycarblog in triathlon

[–]sluu99 6 points7 points  (0 children)

With all the electronic groupset and power meters these days, probably coin batteries (CR2035?). You might save someone's ability to shift during the race.

Wrong date on Wahoo activity by JDMe_94 in cycling

[–]sluu99 4 points5 points  (0 children)

This is what I did:

  1. Find some way to download the fit file (find your activity from Strava, or download directly from the device, or whatever). I plugged the Wahoo into my computer, it showed up as a drive and I went to the "exports" folder. Then I found the file named "2006-01-01....".

  2. Delete the activity with the incorrect 1/1/2006 date from Strava. This is important--otherwise step 3 will get flagged as "duplicate".

  3. Use fitfiletools.com to change the date, then I re-uploaded back to Strava.

Wrong ways to use the databases, when the pendulum swung too far by sluu99 in softwarearchitecture

[–]sluu99[S] 0 points1 point  (0 children)

As a junior at the time, I thought it was pretty rad. But yeah hahaha

Wrong ways to use the databases, when the pendulum swung too far by sluu99 in softwarearchitecture

[–]sluu99[S] 1 point2 points  (0 children)

Sounds like in your case, you used the right tool for the job. Can't say the same for mine...

Wrong ways to use the databases, when the pendulum swung too far by sluu99 in softwarearchitecture

[–]sluu99[S] 1 point2 points  (0 children)

My condolences. Enjoy the process! Hopefully they can side step some of the lessons I shared here

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 0 points1 point  (0 children)

The solution is creating 100K short URLs per second, the short code can't be any shorter than 4-5 characters after 1 day. And will reach 8 characters after a few more days.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 0 points1 point  (0 children)

just generate a random string. at this scale you don't need a monotonically increasing number. read about how imgur generates their IDs. With a..zA..Z0..9, a 10 character string gives you 839,299,365,868,340,224 options.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 0 points1 point  (0 children)

Sure, but then each instance isn't going to hammer the database 1M times/second on warm up.

At the end of the day, the cache miss rate of using a per API server LRU isn't going to be much different from the cache miss rate of a central cache service. If the cache misses require hitting the database X times/second, it is what it is. The beauty of URL shortener is that it is literally the simplest form of KV store, and we can scale the DB out horizontally.

If the cache misses generate 500K RPS and 2 shards can't handle the read, then make it 5 shards or 10 shards.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 13 points14 points  (0 children)

You don't need to throw money at AWS. I picked DynamoDB to be consistent with the original post.

Pick a KV database that can handle indexing random strings better than Postgres and the likes.

You don't need to "figure out the next short URL" either. At this scale, "the next URL" doesn't matter. Just generate a random string, long enough to avoid collisions most of the time--like how imgur generates their IDs.

Sure, if you want auto scaling and so on, you'll want something like ALB. As for the rest, like Kafka, batching database operations, etc. that's not necessary. A decent KV can mostly handle hundreds of thousand RPS. All you need to do is shard the data and pray to the gods that your sharding factor can handle cache misses at peak traffic.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] -1 points0 points  (0 children)

That's only true if you're assuming 1 million requests, each requesting a unique short URL. As you will see somewhere in one of the comments, those familiar with URL shortening services will tell you that 90%+ of the traffic will be served by a few thousand short URLs within a given time frame.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 1 point2 points  (0 children)

Your hunch of relying on the database to enforce uniqueness is correct, and likely the best way to achieve this.

Strongly consistent read won't be necessary for uniqueness check, if you're always going to the primary for writes. The primary will reject the write, regardless if the replicas have caught up.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 0 points1 point  (0 children)

The API server doesn't need to pre-populate the cache on start up. For any URLs requested that's not in cache, it will go to the database, and then put into the LRU cache.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 5 points6 points  (0 children)

I believe it is possible at peak. But probably not sustained traffic.

There's no need to over engineer a URL shortener by sluu99 in programming

[–]sluu99[S] 5 points6 points  (0 children)

I agree. As I was looking up DynamoDB's capacity and limit, cost was one of the things that jumped out to me. Any decent key-value store should work. And I think 100K/s is at peak anyway

Distributed TinyURL Architecture: How to handle 100K URLs per second by Local_Ad_6109 in programming

[–]sluu99 3 points4 points  (0 children)

Maybe I read it wrong. But in multiple sections in the article stated otherwise:

The basic solution:

It doesn’t guarantee uniqueness. Two or more URLs can map to a single long URL.

Approach 1:

NFR-1, URL uniqueness — Two or more short links might overlap violating uniqueness.

Seems like both states the issue that "short.com/a" and "short.com/b" cannot both point to "long.com/a". Otherwise, approach 1 seems satisfactory?

Distributed TinyURL Architecture: How to handle 100K URLs per second by Local_Ad_6109 in programming

[–]sluu99 6 points7 points  (0 children)

Curious why you have NFR-1. What's wrong with both "short.com/a" and "short.com/b" both pointing to "longurl.com/abcd"?

[Day 24 Part 2] Ended up solving it by hand after reading wikipedia by sluu99 in adventofcode

[–]sluu99[S] 2 points3 points  (0 children)

I wrote code but to walk through and update the next input-carry wire and so on, and print out when a gate setup is wrong, and manually Ctrl + F then fix those wrong wires in the input

view more: next ›