This week's system design refresher: Top 7 Most-Used Distributed System Patterns (Youtube video) Amazon Prime Video Monitoring Service RPC vs. RESTful The cost of storage systems Meet New Relic Grok, the World’s First Generative AI Observability Assistant
The text of the RPC vs. RESTful section correctly identifies the two as different design methodologies, but the table is misleading. It’s comparing a couple of RPC and REST frameworks, not the design approaches. For example, it’s perfectly common for RPC frameworks to use human-readable JSON and for REST APIs to use a binary serialization.
Distributed patterns are nice short video. Liked the CQRS like in India we have different food delivery apps like Swiggy, Zomato, etc. The order goes directly from customer to cashier and cashier arranges to prepare while the delivery agent comes later and picks the order to deliver. Also liked the water pipe example for circuit breaker. I liked the bonus pattern the strangler pattern. It is like we have design new systems with that thought so that it can be replaced when newer technology comes up. What I mean is, If the facade itself is not designed in first design we can't implement this "smooth replacement pattern/strangler pattern" in future. https://en.wikipedia.org/wiki/List_of_system_quality_attributes one of attribute is modifiability. The counterpart for new system feature rollout is feature toggle https://tech.co/news/the-dark-launch-how-googlefacebook-release-new-features-2016-04. Regarding sharding this is one important thing to consider while design though they say think of performance bit later. It's easy to decide. Say a user has to choose an option before the service can be useful it's best to split in DB end. Say a service booking app where customer has to choose the city before it can offer services pertinent to that city. In that case for better performance city data can be independently stored per city DB but underground analytics itself can be through datawarehouse. main point "customer choosing while entering" --> "may be candidate for sharding design"
Microservice architecture can address both architectural and organizational problems, although the benefits and challenges vary depending on the specific context.
Architectural Problem: Microservices can solve several architectural problems in software development. They can promote better scalability, as each service can be scaled individually based on its needs, and they can improve fault isolation, since a problem in one service doesn't necessarily affect others. Microservices also promote modularity, which can make systems more maintainable and easier to understand.
Organizational Problem: From an organizational perspective, microservices can help align teams around business capabilities, allowing for more independent and parallel development. This can result in faster time-to-market and more efficiency in development cycles. Each team can use the technologies that best fit their service, leading to better developer satisfaction and productivity.
However, adopting a microservices architecture is not without challenges. It can add complexity to your system, with concerns such as service discovery, distributed data management, and inter-service communication. This approach also requires a mature DevOps capability to manage continuous integration, deployment, and monitoring of many separate services.
Finally, it's worth noting that while microservices can help solve both types of problems, they are not a universal solution and should be adopted with care. A thoughtful, deliberate approach that considers the specific needs and capabilities of the organization and system is essential.
I have a question about the section on how much storage can be purchased for the price of a Tesla. I notice no time factor linked with the evaluations.
Where is the article about the 90% Cost Slash: From Serverless to Monolith?
Here is another discussion about it. https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580. You can find the link in it.
here is video Blog : https://www.youtube.com/watch?v=JTp0TY_2hXM
The text of the RPC vs. RESTful section correctly identifies the two as different design methodologies, but the table is misleading. It’s comparing a couple of RPC and REST frameworks, not the design approaches. For example, it’s perfectly common for RPC frameworks to use human-readable JSON and for REST APIs to use a binary serialization.
Distributed patterns are nice short video. Liked the CQRS like in India we have different food delivery apps like Swiggy, Zomato, etc. The order goes directly from customer to cashier and cashier arranges to prepare while the delivery agent comes later and picks the order to deliver. Also liked the water pipe example for circuit breaker. I liked the bonus pattern the strangler pattern. It is like we have design new systems with that thought so that it can be replaced when newer technology comes up. What I mean is, If the facade itself is not designed in first design we can't implement this "smooth replacement pattern/strangler pattern" in future. https://en.wikipedia.org/wiki/List_of_system_quality_attributes one of attribute is modifiability. The counterpart for new system feature rollout is feature toggle https://tech.co/news/the-dark-launch-how-googlefacebook-release-new-features-2016-04. Regarding sharding this is one important thing to consider while design though they say think of performance bit later. It's easy to decide. Say a user has to choose an option before the service can be useful it's best to split in DB end. Say a service booking app where customer has to choose the city before it can offer services pertinent to that city. In that case for better performance city data can be independently stored per city DB but underground analytics itself can be through datawarehouse. main point "customer choosing while entering" --> "may be candidate for sharding design"
Actually, the most popular RPC framework, gRPC is based on HTTP2. https://learn.microsoft.com/en-us/aspnet/core/grpc/comparison?view=aspnetcore-7.0
Microservice architecture can address both architectural and organizational problems, although the benefits and challenges vary depending on the specific context.
Architectural Problem: Microservices can solve several architectural problems in software development. They can promote better scalability, as each service can be scaled individually based on its needs, and they can improve fault isolation, since a problem in one service doesn't necessarily affect others. Microservices also promote modularity, which can make systems more maintainable and easier to understand.
Organizational Problem: From an organizational perspective, microservices can help align teams around business capabilities, allowing for more independent and parallel development. This can result in faster time-to-market and more efficiency in development cycles. Each team can use the technologies that best fit their service, leading to better developer satisfaction and productivity.
However, adopting a microservices architecture is not without challenges. It can add complexity to your system, with concerns such as service discovery, distributed data management, and inter-service communication. This approach also requires a mature DevOps capability to manage continuous integration, deployment, and monitoring of many separate services.
Finally, it's worth noting that while microservices can help solve both types of problems, they are not a universal solution and should be adopted with care. A thoughtful, deliberate approach that considers the specific needs and capabilities of the organization and system is essential.
next from Amazon: move from REST API to post pigeon. All the world: yes yes we will do it too!
It's an interesting read.
I have a question about the section on how much storage can be purchased for the price of a Tesla. I notice no time factor linked with the evaluations.
How can i contribute in writing the byte byte go articles?