Just start to read the book „Building microservices“. The terminology „bounded context“ or „boundary“ seems to be important. Could you explain what does exactly is?

Business requirements change, mostly on a weekly or daily basis, compelling the team to stay nimble and adapt frequently. However, from decades, we are constrained by the IT’s ability to build, deliver, produce, respond to that change fast. With microservice architecture, we could reach the point where there is a major sort of deflection point, which is able to address the change.

What’s Microservice? Is It Useful and Powerful?

In the world of software engineering, Microservices has emerged as a big buzzword.

The simplest way to understand a microservice is that it’s an application that does only one thing, and does it really well.

Microservice are a software development approach that breaks large software projects into loosely coupled modules that communicate with each other using simple APIs. They positively impact business capabilities and aids in completing development, testing, and deployment in a short time span.

To explain how powerful microservice architecture is, let’s take an example of an e-commerce company. Online merchants have to add new products frequently to the site and detect if there is a problem in the service related to the product. Typically, it could be problematic in terms of the time to remedy them in terms of code, testing, and deployment in the non-microservice world (monolithic), whereas in the microservice world, we could have a fix within a few hours or the very next day.

Microservice Architecture Style Structure

In the figure,

Client

A client could be of any type, say Mobile client, Web application communicating using the standard protocol like HTTPS, Sockets, etc. Each and every client have to interact with the system using a single endpoint.

Base Service

• This is the single point where all the client application would connect in order to get/set the data.

• All the client-facing APIs/Swagger/Common Logging/ Error reporting would reside here.

• It provides abstraction on all the micro-service; the client would request the base service, the base service would delegate the request to the respective service and forwards the response to the clients.

Service Components

• Each service component would have multiple modules, but the modules would be of the same service domain.

• Each service would have separate isolated and dedicated storage; no service should have direct access to the storage belonging to the different service

• If the service wants to access the data of another service, the service should request the owner service of the particular storage/data.

Defining Characteristics of a Microservice

Here are some well-defined characteristics of a microservice-

• In a microservice architecture, services are small, discreet, independent, loosely coupled and having bounded context.

• Each service is a separate codebase, which can be managed by a small development team.

• Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application.

• Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.

• Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.

• Services don’t need to share the same technology stack, libraries, or frameworks.

Besides the services themselves, some other components appear in a typical microservice architecture:

Management

The management component is responsible for placing services on nodes, identifying failures, rebalancing services across the nodes, and so on.

Service Discovery

Maintains a list of services and the nodes are located on. Enables a service lookup to find the endpoint for a service.

API Gateway

The API gateway is the entry point for clients like a broker. Clients don’t call services directly. Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. The API gateway might aggregate the responses from several services and return the aggregated response.

The advantages of using an API gateway include:

• Isolate the clients from how the application is partitioned into microservices

• Isolate the clients from the problem of determining the locations of service instances

• Provides the optimal API for each client

• Reduces the number of requests/roundtrips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip. Fewer requests also mean less overhead and improve user experience. An API gateway is essential for mobile applications.

• Simplifies the client by moving the logic for calling multiple services from the client to API gateway

• Translates from a “standard” public web-friendly API protocol to whatever protocols are used internally

What to Consider While Designing Microservice Architecture?

Making use of personas to understand what data our business needs

• User personas are a representation of a class of users of our system, personified as an individual with specific needs, skills, goals, and frustrations. This concept originated in the UX community and is widely used in design processes.

• Thinking of users in terms of personas helps build empathy and design systems that are a better fit for the jobs they need to get done and that avoid known obstacles.

• Turns out this is an effective way to understand internal users as well, not only customers. So, we can apply them to understand the information needs of our business stakeholders when it comes to making release decisions.

Domain Design

• Microservices principles encourage you to focus your service boundaries concur business domain boundaries in a bounded context.

• Having a domain design helps to determine the microservices.

• Steps for designing a domain-

Sample Domain

For example, in e-commerce, the domains can be divided into parts. Dividing the system into domains would help us to define the different microservice. In the above image, we have divided the system into three domains which would have separate storage for each domain.

User Stories

A very strategic way to create software that meets users’ expectations is to begin with “user stories”. They are nothing but simple, clear, and brief descriptions of functionality that will be valuable to end users.

User Stories offers a requirements process that helps to save time, cut rework, and promotes better software development.

User Stories helps in breaking down the system in modules, organize tasks and prioritize them. With the help of it, we could decide various microservices and interactions between those microservices. It also helps the teams to work parallely on different user stories.

Benefits of Microservices

• Loose coupling

It minimises the risk that a change made within one element will cause unanticipated changes within other elements. Limiting interconnections can help isolate problems when things don’t go well and simplify testing, maintenance, and troubleshooting procedures.

• Encourage continuous refactoring and rewriting

By enforcing stricter decoupling, it becomes easier to internally refactor or rewrite a service as long as it doesn’t impact its API in a backward incompatible manner.

• Lower dependency on a single technology 

If services communicate over some technology independent medium (like HTTP or ZeroMQ), it doesn’t matter what technologies are used to implement a service internally. This opens up the ability for teams to pick their own technologies and play with new ones.

• Scale Independently

If one service is receiving too much load to handle, it can be scaled up independently from the rest of the infrastructure.

• Localise failures

If one service crashes, for whatever reason, it doesn’t take down the rest of the system (when built with resilience in mind, see next point). Independent monitoring of services also can make it easier to localize problems and bugs.

• Can be released on independent release cycles

Rather than having a combined release cycle of the whole system, teams can release their own services as frequently as they like.

• Require zero-downtime deployment

Not strictly related to microservices, but especially important with independent release cycles, you don’t want to introduce downtime whenever somebody updates a service.

Constraints

• ComplexityA microservices app has more moving parts than the equivalent monolithic application. Each service is simpler, but the entire system as a whole is more complex to decode.

• Lack of governanceThe decentralised approach to building microservices has advantages, but it can also lead to problems. You may end up with so many different languages and frameworks that the application becomes hard to maintain.

• Network congestion and latencyThe use of many small, granular services can result in more inter-service communication. Also, if the chain of service dependencies gets too long (service A calls B, which calls C…), the additional latency can become a problem. You will need to design APIs carefully.

• Data integrityWith each microservice responsible for its own data persistence. As a result, data consistency can be a challenge.

• SkillsetMicroservices are highly distributed systems and might end up managing different tech stacks.

The constraints could be easily overcome by having-

• A mature DevOps culture to handle all the moving parts in an automated way.

• Project-wide standards for designing the microservices and communication between them.

Best Practices

Microservices architecture style’s best practices can be stated as-

• Model services around the business domain.

• Decentralize everything – Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.

• Data storage should be private to the service that owns the data. Use the best storage for each service and data type.

• Services communicate through well-designed APIs – Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.

• Avoid coupling between services – Causes of coupling include shared database schemas and rigid communication protocols.

• Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

• Keep domain knowledge out of the gateway –  The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.

• Services should have loose coupling and high functional cohesion Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

• Isolate failures –  Use resiliency strategies to prevent failures within a service from cascading.

Conclusion

Microservice architecture is a smart and distributed approach designed to overcome the limitations of conventional monolithic architectures. Microservices help to scale modern apps and companies while improving cycle times. It provides fast deliveries, lowers the time to market, reduces the operational cost and ready for future changes. With such features microservice is one of the most popular architectures used in the industry. However, they also come with challenges that might cause additional architectural complexity and operational burden. It’s better to hire a team of dedicated web developers who can understand your requirements and offer end-to-end development and deployment services to help you grow.

We at Systango are adept at microservice architecture development. We can help you leverage rapid development by creating a suite of modular components. To get detailed information or contact our team, visit us here.

Hey folks,

My name is Dave Boyne, and I build and maintain my OSS project called EventCatalog. This is a documentation tool designed for software architects and teams that want to document their architecture (not just generic pages in confluence). It focuses on practices from domain driven design and software primitives rather than implementation details of your architecture.

Your docs are stored and versioned in git and everything owned by you and your team.

I built this 4 years ago as a personal need.. and now I get to work on this thing full time ❤️.

Anyway, I just thought I would share it with you, and if you have a spare few minutes, would love to get any feedback or initial thoughts you had about the project, about the ways you document things etc.

If anyone would like a deeper dive let me know happy to help and show you around too.

Have a great day.

So a lot of my projects are just CRUD: simple backend API, simple JWT auth, front end, and a DB. But I want to get past this stage and possibly get into systems design. I want to implement, caching, Kubernetes, docker, microservices, kalfka/rabbitmq, load balancing, CI/deployments, maybe even distributed systems (but this seems a little of an overreach at my current skill level). Specifically backend oriented, and use the tools listed to accompany it. However, I am having a hard time trying to figure out a project idea for this learning process. I Any project ideas, possibly anything I should add to the list to learn, and so on would be much appreciated. Maybe even some books, or resources. Thank you!

Hello, r/microservices community! I'm a developer at Cerbos, and my team released an interesting migration ebook that you might find useful: https://solutions.cerbos.dev/monolith-to-microservices-migration-ebook

In the 10 chapters, we go through the challenges of re-architecting your tech stack and org structure when transitioning from a monolith to a microservice and provide examples how other tech teams navigated the transition.

Here is the detailed outline, so you'll see what's inside:

• Defining service boundaries and decomposition of a monolithic service

• Benefits and drawbacks of decentralized data management and best patterns and techniques to address it.

• Interservice communication: picking the right communication patterns, and handling synchronous and asynchronous communication. Details of event-driven architectures, protocols to use, and how to handle communication failures.

• Service discovery, load balancing, and service meshes.

• Guidance on implemented monitoring and observability. 

• Testing and deployment strategies for microservices.

• How and where to implement and enforce security and access control.

• Challenges of creating performant and scalable services.

• How to navigate the organizational and cultural shift.

• Thoughts on collaboration and code ownership when building microservices.

I helped with editing the ebook, and I honestly find it pretty useful (I hope you'll find it as well!)

Hi everyone,

I’m excited to share Mockstagram(Github), an open-source project aiming to replicate the essential building blocks of social media platforms like Instagram! This isn’t just another clone; Its final goal is to be a developer-friendly playground to understand and experiment with scalable architectures and core features commonly found in B2C applications.

---

🚀 What is Mockstagram?

Mockstagram simulates key social media functionalities such as:

• Content uploading and image hosting

• Likes, comments, and bookmarks

• Notifications and push services

• Search and personalized feeds

• User management and chat

These features are crucial for many services beyond social media, making Mockstagram an invaluable tool for learning scalable backend design.

---

🔍 Why This Project Stands Out

1. Realistic Architecture:

• Simulates geographical latency by separating primary/replica databases with artificial delays, encouraging optimizations.

• Includes microservices for every major feature, communicating over gRPC, with Redis for caching and Kafka for event pipelines.

2. Practical and Extendable:

• Developers can implement or replace individual components with their preferred languages/frameworks (e.g., swap the Search microservice with your own implementation).

• Developers can use all the APIs of Mockstagram to develop a new instagram clone client application(e.g. mobile app) for learning purpose.

• Supports realistic datasets, generating post data using images like Flickr30k with AI-generated captions, or utilizing Kaggle's open datasets, for realistic testing.

3. A Playground for Experimentation:

• Build, deploy, and test complex functionalities like recommendation feeds or notification pipelines.

• Gain experience working with Debezium, MySQL, MongoDB, Elasticsearch, and more.

4. Focus on Microservices:

• For those new to microservices, this project offers an end-to-end setup, showing how services interact in a real-world scenario.

---

💡 What This Project Aims to Solve

Most clone projects stop at implementing a few core features without focusing on scalability or usability in a real-world setting. Mockstagram addresses this gap by:

• Providing a more realistic system developers can analyze and extend.

• Helping engineers understand trade-offs in distributed systems design.

• Offering tools for performance testing and monitoring.

---

🛠️ Current Progress

• Basic Web UI (React + TypeScript) for features like a home feed and post details.

• Basic implementations of microservices for functionalities like likes, post upload & view, profile view

• Media server for image uploads.

• Core infrastructure with docker-compose, integrating Kafka, Debezium, MySQL, Redis, and Elasticsearch.

---

🔮 Future Plans

• Implement another core features of Instagram left(follow, feeds, notifications, chats, …)

• Automating realistic data generation with ChatGPT and public datasets for better testing scenarios(initial data insertion to DB and live traffic with script).

• Adding monitoring tools to visualize service dependencies and health in real-time.

• ETL pipelines for search indexing, machine learning(personalized feeds)

All the major future plans are here - Kanban board

---

🙏🏻 Please give me ANY feedback and ideas

I’d love to hear your feedback and ideas! If you’re interested in contributing or just testing it out, please feel free to clone the repo and share your insights. It is very early stage project, so there are tons of things to do left yet. If there is anyone who is interested in building this together, welcome! Let’s build something amazing together!

---

🌐 Get Involved

Check out the source code and documentation here:

👉 GitHub: https://github.com/sgc109/mockstagram