{
  "id": 10136877,
  "title": "Day 22 — Microservices vs Monolith — Hype বাদ দিয়ে সত্যিটা বলি",
  "url": "https://urgent.news/2026/09/27/day-22-microservices-vs-monolith-hype",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-27T04:20:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mislam-dev/day-22-microservices-vs-monolith-hype-baad-diye-styittaa-bli-3872"
  },
  "original_language": "en",
  "account": "Day 22 - Microservices vs Monolith: Separating Fact from Hype\n\nA company's application is running well with multiple teams, around 100-120 members. The team decided to optimize the system after noticing performance issues. They conducted monitoring for a week, analyzing data on which services were used most and which had higher latency. It was found that feed and chat-related services were the most used, while payment-related services were used less frequently. Additionally, teams provided feedback indicating performance drops and maintenance challenges due to the monolithic application structure.\n\nIn a monolithic application, all code resides in a single codebase and deployment, which simplifies development but becomes problematic as the codebase grows. Issues such as codebase expansion, merge conflicts, and scalability limitations arise, making it difficult to scale individual parts of the application or handle high traffic on specific features like the feed page.\n\nMicroservices offer a solution by breaking the application into smaller, independent services based on domains and use cases. Each service functions as a standalone application, with its own logic, implementation, and even database. This allows for independent deployment, scaling, and team ownership of services, leading to easier code maintenance and reduced merge conflicts.\n\nHowever, microservices also come with challenges such as increased network latency due to communication between services, distributed transactions, and complex debugging. Additionally, the infrastructure complexity rises, making it difficult to manage and maintain multiple services.\n\nFor startups, a modular monolith could be a suitable middle ground. This approach combines the simplicity of a monolith with the benefits of modularity, allowing for gradual transition to microservices if needed. A modular monolith structure involves organizing code into modules, each with its own domain and database schema. This allows for easy incremental conversion to microservices when the application scales and requires more independent development and deployment.\n\nIn conclusion, the choice between microservices and monolith depends on the specific needs and size of the team, as well as the product's business domain and scalability requirements. Startups should consider starting with a monolith to quickly iterate and understand the domain before transitioning to microservices if necessary.",
  "summary": "আপনার application এখন ভালোভাবেই চলছে। আপনি এখন আর একা কাজ করেন না। আপনি কয়েকটি team build করেছেন। অনেকদিন ধরেই এই team building-টা চলছে। মোটামুটি ১০০-১২০ জনের team আপনারা operate করছেন। এখন আপনার ইচ্ছা জাগল যে system-টা optimize করা দরকার। এর জন্য শুরু করলেন system monitoring। এভাবে ১ সপ্তাহ monitoring করলেন। ১ সপ্তাহ পর আপনার কাছে সব data চলে আসলো। আপনি কিছু জিনিস খেয়াল করলেন: Feed এবং Chat…",
  "key_points": [
    "Microservices vs monolith analyzed after performance issues",
    "Feed and chat services most used, payment services least used",
    "Modular monolith suggested as middle ground for startups"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}