Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Designing Your Web Application for Millions of Users When You Dont Have 100

darrenhorrocks.co.uk

Post reply on HN
Print view View original

61–70 of 103 posts

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#61

Post by myprotegeai »

mewpmewp2 wrote: post #53
myprotegeai wrote: post #20

This topic lacks nuance. I agree in focusing on building things that people want, as well as iterating and shipping fast. But guess what? Shipping fast without breaking things requires a lot of infrastructure. Tests are infrastructure. CI and CD are infrastructure. Isolated QA environments are infrastructure. Monitoring and observability are infrastructure. Reproducible builds are infrastructure. Dev environments are…

Nowadays there are a lot of tools to setup this infra in a standard way very quickly though - in terms of CI/CD, tests, e2e tests etc.

There is no "standard way", only rough principles, and it all depends on the unique DNA of the company (cloud, stack, app deployment targets, etc). Yes there are a lot of tools, and experienced infrastructure engineers spend a lot of time integrating them. Often times they won't work without enormous effort, because of early "move fast & break things" design decisions made by the org. My experience has been that a startup is only using these tools from early on if they have experienced engineers and a management that understands the importance of building on a reliable foundation.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#62

Post by Jach »

xandrius wrote: post #25
nine_k wrote: post #13

Earlier quoted context omitted.

If that optimization is mere hours of work, I would go for it outright. BTW when you have an overwhelming wave of signups, you are likely to have more pressing and unexpected issues, and badly lack spare hours. Usually serious gains that are postponed would require days and weeks of effort. Maybe mere hours of coding proper, but much longer time testing, migrating data, etc.

I think that's the pitfall: there are infinite things a skilled developer can do within "mere hours of work". The key is to find which ones are the most effective use of one's limited hours. I developed a small daily game and it has now grown to over 10K DAU, so now I've started going back to refine the low hanging fruits which just didn't make sense to touch when I had just 10s of players a day.

We might all be operating under different ideas of what "matter of hours" means. Often times in a project, at least for me, the range of things that I can start and finish in mere hours is not actually infinite, but rather constrained. Only the simplest and smallest things can be done so fast or faster. So many other things just take longer, at least a day and a half, and can take extra long when other teams are involved. More experienced developers can learn how to break things down into increments, so while an entire big feature might take weeks to do, you're making clear chunks of progress in much smaller units. Those chunks are probably not mostly sized in mere hours pieces, though...

You're right that priority matters. Just beware of priority queue starvation. Still, if some newly discovered bug isn't urgent, even if I think it'd be rather easy (under an hour) to fully address, I'd rather not break my current flow, and just keep working on the thing I had earlier decided was highest priority. A lot of the time something will prevent direct progress and break the flow anyway, having smaller items available to quickly context switch to and finish is a good use of those gap times.

The "DB handling 100x the traffic" example above isn't quite well defined. I wonder if it's making queries return 100x faster? Or is it making sure the queries return at roughly their current speeds even if there's 100x more traffic? Either way, I can make arguments for doing the work proactively rather than reactively, but I'd at least write down the half a dozen things. Then maybe someone else can do them, and maybe those things can be done in around half a dozen tiny increments of 30 minutes or less each, instead of all at once in hours.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#63

Post by leosanchez »

bsenftner wrote: post #60
poincaredisk wrote: post #57

Earlier quoted context omitted.

It really depends on the project. For a CRUD application? Sure. For an application that processes hundreds of events per second, stores them, and makes them wueryable using various filters? Can get tough real quick.

That's where SQLite really shines - used it in a massively scaled facial recognition system, with several hundred simultaneous cameras, a very large FR database with over 10K people, each having dozens of face entries, and all the events that generates from live video viewing large public venues. SQLite was never a bottleneck, not at all.

Single sqlite db or did you shard it ?

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#64

Post by poincaredisk »

dspillett wrote: post #16

[caveat: not read the text because if you click the partners link onthe nag box, it looks like I need to object to each “legitimate interest” separately and I've not got time for that – congratulations darrenhorrocks.co.uk on keeping your user count lower, so you don't have to design for higher!] The problem often comes from people solving the problem that they want to have, not the ones that they currently have. The…

>It looks like I need to object to each “legitimate interest” separately and I've not got time for that

I absolutely don't understand why some websites do this. Either don't show them or don't make them annoying to disable. Let me explain:

Legitimate interest is one of the lawful reasons for processing personal data. They don't have to ask for your permission. Usually adspam cookies are not in your legitimate interest, so they have to resort to another lawful basis, which is user consent. But they claim "legitimate interest" covers these cookies, so why even ask?

But on the other hand, I often stubbornly disable legitimate interest cookies, and not once I broke the website this way. This is suspicious - "legitimate interest" means that it's crucial to doing what you want to do on the website, for example a session cookie or language selection cookie. If the website works normally without a "legitimate interest" cookie, them the interest was not legitimate at all. I assume this is just some trick abused by advertisers to work around GDPR, and I wish them all 4% of global turnover fine.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#65

Post by anal_reactor »

zimpenfish wrote: post #4

At a previous job, there was an argument over a code review where I had done some SQL queries that fixed a problem but were not optimal. The other side were very much "this won't work for 1000 devices! we will not approve it!" whereas my stance was "we have a maximum of 25 devices deployed by our only customer who is going to leave us next week unless we fix this problem today". One of the most disheartening weeks of…

I'm stunned to realize that most developers just blindly follow whatever are the newest hottest "good practices" and completely ignore the actual goals that code should try to achieve. Literally yesterday I had an argument with a coworker because he wouldn't buy the argument "High-availability costs us $2000 per year extra, downtime costs us $100 per day, so if the database breaks once per year, there's no point having high-availability". Some time ago someone important from upper management announced that we need to pump out features faster to stay afloat as a business, even if they're a bit broken, and two hours later the most senior programmer in my team introduced us to new bureaucracy "because that's the best practice" and he wouldn't understand that what he's doing is directly at odds with the company's goals. Same guy also often accuses me of "not seeing the bigger picture". I gave up trying to reason with coworkers because it's just pain and changes nothing in the long run besides exhausting me.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#66

Post by oliwarner »

The ethos described in TFA extends a lot further than this vague idea of "scale". Be honest. We've all built things without a test framework and 99.9% coverage. Many all the way to production and beyond. Many of us skimp on accessibility. Works For Me™ means it Works For Client™ and that's all anyone will budget for. Even client optimisations (bundling/shaking/compressing/etc) get thrown out the window in a hurry.

The problems with accepting this way of thinking is you never budget for cut corners. After you build the MVP, all your client/boss wants is the next thing. They don't want to pay you again to do the thing you just did, but right.

And if you never get approval for testing, a11y, optimisations, the first time you hear about it is when it has lost you users. When somebody complains. When something breaks. Those numbers really matter when you're small. And it always looks bad for the devs. Your boss will dump on you.

So just be careful what corners you're cutting. Try to involve the whole team in the process of consciously not doing something so it's not a shock when you need to put things right later on.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#67

Post by zimpenfish »

Jach wrote: post #62
xandrius wrote: post #25

Earlier quoted context omitted.

I think that's the pitfall: there are infinite things a skilled developer can do within "mere hours of work". The key is to find which ones are the most effective use of one's limited hours. I developed a small daily game and it has now grown to over 10K DAU, so now I've started going back to refine the low hanging fruits which just didn't make sense to touch when I had just 10s of players a day.

We might all be operating under different ideas of what "matter of hours" means. Often times in a project, at least for me, the range of things that I can start and finish in mere hours is not actually infinite, but rather constrained. Only the simplest and smallest things can be done so fast or faster. So many other things just take longer, at least a day and a half, and can take extra long when other teams are invo…

> Or is it making sure the queries return at roughly their current speeds even if there's 100x more traffic?

From what I remember, it was this. The DB was MySQL and a whole bunch of stuff would have been less efficient when there were 1000 devices instead of 25. But on the other hand the system was broken and the customer was threatening to cancel everything and fixing the DB stuff was going to take a fair amount of rearchitecting (not least dumping MySQL for something less insane) that we didn't have the time or resources to do in a hurry.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#68

Post by nine_k »

xandrius wrote: post #25
nine_k wrote: post #13

Earlier quoted context omitted.

If that optimization is mere hours of work, I would go for it outright. BTW when you have an overwhelming wave of signups, you are likely to have more pressing and unexpected issues, and badly lack spare hours. Usually serious gains that are postponed would require days and weeks of effort. Maybe mere hours of coding proper, but much longer time testing, migrating data, etc.

I think that's the pitfall: there are infinite things a skilled developer can do within "mere hours of work". The key is to find which ones are the most effective use of one's limited hours. I developed a small daily game and it has now grown to over 10K DAU, so now I've started going back to refine the low hanging fruits which just didn't make sense to touch when I had just 10s of players a day.

Exactly. Going for something that shaves 5% off your hosting bill or your build time only makes sense when you are already colossal. But something that halves your bill, or halves your build time, or halves your latency, is likely impactful if your project achieves the scale when the proceeds from it can support you.

And very often an optimization improves things not by factor of 1.1 but by factor of 10 or more.

OTOH it's worth to be mindful of your "tech debt" as a "tech credit" you took to be able to do more important things before it's time to repay. Cutting your hosting bill from $100 to $50 may be much less important than doubling your revenue from $500 to $1000.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#69

Post by jasfi »

ForHackernews wrote: post #26

I dunno, I've lived the other side of this where people made boneheaded choices early on, the product suddenly got traction, and then we were locked into lousy designs. At my last company, there were loads of engineers dedicated to re-building an entire parallel application stack with a view to an eventual migration. A relatively small amount of upfront planning could have saved the company millions, but I guess it w…

More experienced software engineers can usually make the right design decisions that don't mean rebuilding when/if it comes time to scale things. This is usually about avoiding bad decisions because they know better.

Re: Stop Designing Your Web Application for Millions of Users When You Dont Have 100

#70

Post by ManBeardPc »

dig1 wrote: post #59
ManBeardPc wrote: post #28

People seriously underestimate the amount of clients you can serve from a single monolith + SQL database on a VPS or physical hardware. Pretty reliable as well, not many moving parts, simple to understand, fast to setup and keep up to date. Use something like Java, C#, Go or Rust. If you need to scale you can either scale vertically (bigger machines) or horizontally (load-balancer). The SQL database is probably the h…

People also underestimate how financially predictable this setup is - you purchase a VPS or bare metal box on DigitalOcean/Hetzner/OVH for e.g. $50/mo, and that price will likely stay the same for the next 5 years. Try that with any of the cloud providers. This part is often neglected when running a company, where owners usually hope infra costs will decrease over time or remain proportional to company income. Howeve…

Good point. Hardware resources are significantly more expensive in the cloud. It is not even close. For basic setups and no insane scaling requirements (most CRUD apps) I don't think you can beat the VPS/bare-metal offers from the mentioned providers. Support is often superb as well.
Post reply on HN