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

21–30 of 103 posts

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

#21

Post by throwaway48540 »

renatovico wrote: post #18
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…

totally agree with your view, the big design upfront moment again, maybe because of the current economy, we need focus more on be profitable in short term, i think it's great and always focus on optimize for now, and test for specs (specs in sense of requirements of customer)

I really don't think that's the case. If you ask a CEO/CTO of a startup, he would fire the guy who did the latter instead of the middle approach. Longer term stability and development velocity are very important concerns in engineering management. This is pure inexperience - it wouldn't take too long to setup for an experienced engineer anyways, they probably did it 5 times last month and have a library of knowledge and templates. I can't call a guy who isn't capable of setting up a project this way swiftly without seeing it as a problem "senior".

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

#22

Post by willvarfar »

b112 wrote: post #7
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 actually like having room for optimization, especially when running my own infra servers included. As an example, I can think of half a dozen things I can currently optimize just in the DB layer, but my time is being spent (sensibly!) in other areas that are customer facing and directly impacting them. So fix what needs to be fixed, but if there was a major load spike due to onboarding of new clients/users, I could…

Usually a good trick is to run small deployments at high logging levels. Then, as soon as there are performance issues, you can dial down the logging and get the hours of respite needed to actually make a bigger algorithmic improvement.

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

#24

Post by pjc50 »

KronisLV wrote: post #14

I've seen a bunch of things. Sometimes you have people who try to build a system composed of a bunch of microservices but the team size means that you have more services than people, which is a recipe for failure because you probably also need to work with Kubernetes clusters, manage shared code libraries between some of the services, as well as are suddenly dealing with a hard to debug distributed system (especially…

> a system composed of a bunch of microservices but the team size means that you have more services than people

The thing I keep trying to get people to recognize in internet discussions of microservices is that they're a solution to the organizational problems of very large companies. The right size is one "service" per team but keeping the team size below the "two pizza limit" (about eight people, including the line manager and anyone else who has to be in all the meetings like scrum masters etc).

If your website needs to scale to hundreds of developers, then you need to split up services in order to get asynchronous deployment so that teams can make progress without deadlocking.

Scaling for a high number of users does not require microservices. It does as you say require multiple instances which is harder to retrofit.

> additional negative points for it being Oracle

Amen.

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

#25

Post by xandrius »

nine_k wrote: post #13
b112 wrote: post #7

Earlier quoted context omitted.

I actually like having room for optimization, especially when running my own infra servers included. As an example, I can think of half a dozen things I can currently optimize just in the DB layer, but my time is being spent (sensibly!) in other areas that are customer facing and directly impacting them. So fix what needs to be fixed, but if there was a major load spike due to onboarding of new clients/users, I could…

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.

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

#26

Post by ForHackernews »

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 would have meant less work for engineers so I suppose I should be glad that firms keep doing this.

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

#27

Post by xandrius »

255kb wrote: post #12

Guilty! I spent so much time recently asking myself and trying to optimize my app and stack: - what if people upload files that big, what about the bandwidth cost? - what if they trigger thousands of events X and it costs 0.X$ per thousands? Fast forward months, it's a non issue despite having paying customers. Not only I grossly exagerated the invidual user's resources consumption, but I also grossly exagerated the…

Yeah, I have to keep fighting the feeling that I'm not doing things the "right" way as they are so unlike the $JOBs$ I had before, with availability zones, auto-scaling, CDNs, etc.

I have the most adhoc, dead simple and straightforward system and I can sleep peacefully at night, while knowing I will never pay more than $10 a month, unless I decide to upgrade it. Truly freeing (and much easier to debug!)

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

#28

Post by ManBeardPc »

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 hardest part to scale, but depending on your type of app there is a lot of room with optimizing indices or add caching.

In my last company we could easily develop and provide on-call support for multiple production critical deployments with only 3 engineers that way. Got so little calls that I had trouble to remember everything and had to look it up.

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

#29

Post by xandrius »

rkachowski wrote: post #8

almost 20 years ago the exact same sentiment was expressed in the ground breaking classic "I'm going to scale my foot up your ass" by Ted Dziuba http://widgetsandshit.com/teddziuba/2008/04/im-going-to-scal...

I've got 99 problems but scalability ain't one.

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

#30

Post by dambi0 »

throwaway48540 wrote: post #21
renatovico wrote: post #18

Earlier quoted context omitted.

totally agree with your view, the big design upfront moment again, maybe because of the current economy, we need focus more on be profitable in short term, i think it's great and always focus on optimize for now, and test for specs (specs in sense of requirements of customer)

I really don't think that's the case. If you ask a CEO/CTO of a startup, he would fire the guy who did the latter instead of the middle approach. Longer term stability and development velocity are very important concerns in engineering management. This is pure inexperience - it wouldn't take too long to setup for an experienced engineer anyways, they probably did it 5 times last month and have a library of knowledge…

What is the middle approach in this scenario? What specifically are the templates you refer to?
Post reply on HN