common pattern. That is, each sub-service within a given project - has a single table!
Coming from a Rails driven traditional MVC and Web-API/ SPA-Client world where I manage most of our data needs within a single database, This is new to me. Ngl, Looks like an overkill. I am more comfortable with building data model and relationships within a single database.
First Question: Is this observation correct? Do I need to split an application down even to an individual table level? What is the general rule to follow here?
Second: How do I counter the communication/ processing lag to render a response that relies on data from multiple services? It can be a big ask, I just need some direction here.
No and Yes, it will depend, if your model, for example if you are going to take 5k, 10k, 15k etc. of beating per req/s the correct answer is yes, if not the answer may be no. It will depend a lot on the need of the project, for what you described your projects are mostly a monolith you can have a hybrid of this there depending on the need of course. There is no general rule, there are problems and needs to be solved with an architecture that best suits reality. When you work with a distributed system, communications with FRONT whatever the web, mobile etc. it has to be via websocket or long pool or some service that will communicate with your frontend with the answers.
Durability: What happens if your monolith fails? Right: everything fails, the entire business is down. This is really bad! If you split things up - some parts of the system might go down, for example you're unable to make orders, but you can still view and search through existing orders since those parts are operated by different microservices. Development: When you're working on a big business project, then you probably have a team of dozens of people all working on different parts of the system. Decoupling logic and data allows for better scalability and less friction during development. A microservice architecture isn't a universal solution since there's no silver bullet in software development. Sometimes when a simple monolith is the better option.
That's a strong case for microservices. I guess you have to think of frontend interface too quite differently, to hide all the disjointed data and accommodate such service failures. Going through one such tidy example would be great to pick and learn from.
usually, I have a gateway service that clients talk to (through REST or GraphQL or similar) That gateway service has access to individual microservices. The frontend is not allowed to talk to individual services, it doesn't even know them, they're in their own network inaccessible from the internet.
How do you scale the gateway service?
you just replicate it, which is easy to do since it's stateless
Yes something like apigee or mulesoft. Interesting, I have briefly worked on one. I was referring to how a frontend written using a react component architecture would have to accommodate for service failures in such a landscape, to render a consistent sort of experience.
Yes all you would really need a copy of your rules.
Erlang/OTP primitives solve the durability problem. OTP has supervision trees, which supervise other Erlang processes and supervisors. This way Erlang does ensure durability even with a monolith. Your system will still run if one component fails. That component will be restarted according to the chosen strategy. Ofc it can't save you from a full node failure
I don't see anyone rushing to write new things in Erlang tho 😅
Well it's a nice in web services, but it's really widely used in telecom due to all the concurrency and fault tolerant stuff OTP and BEAM provides
The stuff is indeed fascinating! https://www.cnblogs.com/bozhang/articles/3153031.html
2013, oof, that article's 8 years old
The core design of OTP hasn't changed much. It worked 8 years ago, it works now :)
Обсуждают сегодня