61–70 of 98 posts
do this with bigger & bigger end vision but with a doable MVPin mind.
look at good examples.
open source the result,
https://www.makepostsell.com/ (python, Pyramid, sqlalchemy)
Checkout highscalability.com, used to have lots of real word scalability issues and solutions back on the day. If you want hands on experience, pick an open source app in the language you know and deploy it somewhere and load test till it breaks and see which part breaks first. It could be your load balancer can’t handle that many connections or you app server rubs out of memory or the db comes to a crawl. The more r…
Earlier quoted context omitted.
If you want to build your skills, sure go ahead. But working at a company like this is not a good way to build your wealth. You're far better off working at a big tech company that has awesome benefits or a fresh startup. Startups that have been around long enough to have a legacy code base aren't a place to become wealthy.
Not everyone aims to be wealthy. Most companies do pay a decent salary (specially in europe) with good work life balance. High paying jobs often correlates with high stakes which means potentially higher level of stress.
- learn docker / docker-compose - tie a websocket server, a task queue, and 2-3 http microservices together - you don't have to have many resources, maybe 4-5 endpoints that go through all services - have a client javascript front like react - (bonus for grpc communication for intermediary connections between microservices) - try to break it/ fix it as much as you can. - along the way you'll introduce yourself to timeouts, retries, rate limiting, and other secure practices.
watch guarav sen or hussein nasser on youtube - they are extraordinary resources for aspiring and even competent backend architects
You get hands on experience at a place 1. That has a functioning app AND 2. Business is growing rapidly bringing more customers than the system can handle. In other words you learn on the job by getting your hands burnt. I got lucky to have joined such a startup. Learnt a lot, from fixing DB queries, designing asynchronous order processor, using CDN etc. I worked on scaling up the full stack including stuff like conn…
Ask yourself:
- What constitute a _good_ infrastructure?
- Something flexible/adaptable ?
- Something predictable ?
- Something resilient ?
- Something easy to monitor ?
- Something else ?
- How do you prioritize these, who gets to decide which one matters most...
Architecture is asking a lot of questions, inviting others who will benefit/use your work into the decision making process.
One thing that I learned that is still helpful to me today is try to push as many decisions as possible to later, keep the door open for futur choices. Every system architecture is part invention, part discovery. As you put together your foundation, new requirements/restrictions will appear and you'll be happy to have the freedom to make some of your decisions then.
- what happens if this stuff fails (and how to test it, how to analyze it)
- what attack surface that stuff has
- how to scale if it receives x10 requests or becomes x10 bigger
- how can you explain to a new coworker how it works, how all the decisions were made
You learn large scale system design via real world application, being in the room when it happens, and from closely working with folks who are already practicing it. This kind of work is sometimes as much art as it is science, highly specific to the situation at hand and requirements of the system to be designed. It absolutely bothers me that the resources out there are few and far between. It is hard to change that.…
System design interviews have so far been a bit hit or miss for me. All the interviewers seem to be looking for something, but I’ll be damned if I know what it is. I think I’m inclined to incrementally solve potential problems with the system (as introduced by the interviewer), where a lot of these interviews seem to want you to anticipate all issues. So asking lots of questions about what they want is probably a fir…