Monoliths are self-contained independent applications that are built as a single unit. It doesn’t work just for a single problem but cares for each step of the business need required on the application.
Modular Monoliths
Further, we have modular monoliths where we build and deploy a single application. It breaks the code into independent modules for each feature required in the system. The good thing about modular monoliths is that it reduces the dependencies of a module since they can improve a particular module without affecting the other.
However, if the modular monoliths are implemented correctly, it helps lessen the complexity that grows as time goes by and the system grows consequently.
Distributed Monolith
Moving on, there is distributed monolith that resembles the microservice architecture in many ways. But the difference is that the monolithic application is tightly coupled. Choosing microservices over monoliths is better but when we might get the monoliths while we still go for the microservices.
Let’s see some ways we know that our microservice is the distributed monolith.
- Tightly coupled system.
- Scaling is difficult.
- Dependency between the services.
- Shares the same resources as the database.
- Low-latency communication is needed.
The main purpose for the use of microservices instead of monoliths is to have scalability in a loosely coupled application where every service is independent. With the distributed monolith, the complexity is increased since all the services depend on one another.
Advantages of monoliths
- Developing is simple and easy.
- Communication is fast and reliable.
- Debugging is easy.
- Easy monitoring and testing.
- ACID transactions are supported.
Disadvantages of monoliths
- If the codebase grows larger, maintenance might be difficult.
- The application redeploys each time there is an update.
- The applications are hard to extend because of the tightly coupled feature.
- It requires a commitment to a particular technology stack.
- A single bug can cause the whole system failure — no reliability.
- Might be a nightmare if we need to scale or adopt new technologies.
pragyaasapkota
/
System-Design-Concepts
Though the concepts of system design might be tricky, let's see them individually to their core concepts and have a better understanding.
System Design
Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements.
This is a index for the concepts of system.
If you wish to open these in a new tab, Press CTRL+click
| S.N. | Table of Content |
|---|---|
| 1. | Caching |
| 2. | Network Protocols |
| 3. | Storage: The Underrated Topic |
| 4. | Latency and Throughput |
| 5. | System Availability |
| 6. | Leader Election |
| 7. | Proxies |
| 8. | Load Balancing |
| 9. | Endpoint Protection |
| 10. | HTTPS: Is it better than HTTP? |
| 11. | Polling and Streaming |
| 12. | Long Polling |
| 13. | Hashing |
| 14. | CAP Theorem |
| 15. | PACELC Theorem |
| 16. | Messaging and Pub-Sub |
| 17. | Database |
| 18. | Logging, Monitoring, and Alerting |
| 19. | Distributed System |
| 20. | Scaling |
| 21. | Event Driven Architecture (EDA) |
| 22. | CQRS |
| 23. | Message Queue |
| 24. | Architectural Patterns |
| 25. |
I hope this article was helpful to you.
Please don’t forget to follow me!!!
Any kind of feedback or comment is welcome!!!
Thank you for your time and support!!!!
Keep Reading!! Keep Learning!!!
Top comments (0)