3 ms·

i would say experimentation. trying implementing different arichtectures with relatively simple implementations. one thing that helped me was getting books and

i would say experimentation. trying implementing different arichtectures with relatively simple implementations. one thing that helped me was getting books and articles about different design principles architectural ideas etc. and then creating them myself. Also, what is 'good' here? i am assuming, knowing when to use what kind of architecture. some are easier to create, some perform better, some are easier to collaborate on in large teams, costs can be a factor too. Are you looking for a specific thing or wanting to generally know more about the topic.?

akkad33 3y ago
I have a specific thing in mind, but I think I lack sufficient knowledge of what's out there to make the best trade off for my specific use case. To be honest, I lack basic knowledge of different system components. To give an example I know redis is a key value store. But i wouldn't know the drawbacks of using it and what usecases its best use is for. I would like to broaden my knowledge in order to answer such questions as my job requires me to go from a data scientist to more of a solutions architect
- wanapreneur 3y ago
  Try practicing system design on https://codemia.io https://codemia.io. there's Instant interactive feedback and also evaluation of your answer by AI.
- jpc0 3y ago
  "Gall’s Law: all complex systems that work evolved from simpler systems that worked." Do the simplest thing that works, if that is hosting something on a VM with SQLite for persistent storage than that is what you implement. If what you had in memory was a map or a queue and you don't care about persistence then redis is likely going to serve you well when you need to scale to more than one instance, if you never need more than one instance then keep it in memory as a map or a queue. Don't add things "because that is what :bigtech: does" :bigtech: is not you and if it was, you would have the team to do it or would be building the team and not the software.
  - AnimalMuppet 3y ago
    There's a balance here. To paraphrase the parent: Don't spend much effort solving problems that you don't have yet, and may never have. On the other hand, try not to paint yourself into a corner, where you can't grow (if you do) without a major restructuring of the architecture. This takes having some idea of what the problems can be, and what people do to handle them. You don't have to implement those things yet, but try to build what you build in a way that will be friendly to those changes if they happen.
    - jpc0 3y ago
      I don't disagree but I generally do this by putting thw abstractions in place ij the software. An example is for crud, use the (onion|hexagonal|whatever you want to call it) architecture, you business logic has nothing to do with how the data is stored persistently (or not), build your application using abstract APIs. It's slightly more code up from but if I was using a map in memory it is trivial to move to using redis if I build with the abstractions in place to begin with. Generally in the prototype stage I won't care about that either but I expect the prototype / poc code to be deleted. Same idea with SQLite, moving feom sqlite to a full blown database isn't that difficult but this is one of the places where I would conceded and say if you have the infra in place just use what is available, it may be easier to get a DB on thr current cluster in the long run if there is already a cluster that you can get a DB on. If you however are in a completely greenfields position and really have no idea where the product is going, sqlite scales to a decent amount of RPS and so does a simple go/rust server on a host. Many webservices really don't need more than that and not worrying about being distributed when you don't know if you ever do need to be distributed makes whole hosts of problems trivial to solve and allows you to use technologies that would usually be inconvenient.

akkad33 3y ago

I have a specific thing in mind, but I think I lack sufficient knowledge of what's out there to make the best trade off for my specific use case. To be honest, I lack basic knowledge of different system components. To give an example I know redis is a key value store. But i wouldn't know the drawbacks of using it and what usecases its best use is for. I would like to broaden my knowledge in order to answer such questions as my job requires me to go from a data scientist to more of a solutions architect

wanapreneur 3y ago
Try practicing system design on https://codemia.io https://codemia.io. there's Instant interactive feedback and also evaluation of your answer by AI.
jpc0 3y ago
"Gall’s Law: all complex systems that work evolved from simpler systems that worked." Do the simplest thing that works, if that is hosting something on a VM with SQLite for persistent storage than that is what you implement. If what you had in memory was a map or a queue and you don't care about persistence then redis is likely going to serve you well when you need to scale to more than one instance, if you never need more than one instance then keep it in memory as a map or a queue. Don't add things "because that is what :bigtech: does" :bigtech: is not you and if it was, you would have the team to do it or would be building the team and not the software.
- AnimalMuppet 3y ago
  There's a balance here. To paraphrase the parent: Don't spend much effort solving problems that you don't have yet, and may never have. On the other hand, try not to paint yourself into a corner, where you can't grow (if you do) without a major restructuring of the architecture. This takes having some idea of what the problems can be, and what people do to handle them. You don't have to implement those things yet, but try to build what you build in a way that will be friendly to those changes if they happen.
  - jpc0 3y ago
    I don't disagree but I generally do this by putting thw abstractions in place ij the software. An example is for crud, use the (onion|hexagonal|whatever you want to call it) architecture, you business logic has nothing to do with how the data is stored persistently (or not), build your application using abstract APIs. It's slightly more code up from but if I was using a map in memory it is trivial to move to using redis if I build with the abstractions in place to begin with. Generally in the prototype stage I won't care about that either but I expect the prototype / poc code to be deleted. Same idea with SQLite, moving feom sqlite to a full blown database isn't that difficult but this is one of the places where I would conceded and say if you have the infra in place just use what is available, it may be easier to get a DB on thr current cluster in the long run if there is already a cluster that you can get a DB on. If you however are in a completely greenfields position and really have no idea where the product is going, sqlite scales to a decent amount of RPS and so does a simple go/rust server on a host. Many webservices really don't need more than that and not worrying about being distributed when you don't know if you ever do need to be distributed makes whole hosts of problems trivial to solve and allows you to use technologies that would usually be inconvenient.