Distributed Apis

Following all discussions that I had recently with lots of SDE , SA and Tech Leaders there are some common parts they know all about Microservices and distributed services as best as possible , theses are likes:

• Calling Http endpoints
• Managing Failures and retries
• Circuit-Breaking
• Fallback
• Auto-scaling
• Bounded context
• Continuous Delivery
• …

But there must be other points in the list which no one talks about enough or maybe they don’t care deeply about.

• Instrumenting
• Contract
• Consumer Life Cycle Care
• Inter-component Communication

Again there are lots of points to think about but i share just the ones i will point here and the ones i think is life savers in SDLC and ALM

Instrumenting:

A Microservice needs be instrumented to simplify its Life Cycle management and Team life. Basically a microservice must be delivered in an daily , weekly or … manner. Instrumenting helps have better vision about its consumption, internal state and failures. so solving problems can be faster and testing new functionalities will be better done.

In my experience, I woke up morning with a coffee in hand , looking my email and WOW a customer directly emailed saying i just disconnected my internal service and there is a problem by data they received from our service. I had nothing more important that think about the service Instrumenting state, and find internal state of service for that customer, and look at what’s happening for further requests. Just look at service logs , Monitoring and detailed Observation Dashboard, and all theses happened in just 20 minutes and in 1hour the problem was solved.

In my experience as well , i had a performance problem in which was bringing lots of argues by my customer. instrumenting as well helped to find a better solution and we could optimized our performance just in 2 work days. there I just brought out all request durations and memory consumption per customer and we could finally analyze the different kinds of customer requests.

Without instrumenting you have no vision about system and problems.

The Instrumenting contains

• Observability
• Versioning
• Documentation
• Security Management

Contract:

Any service needs a consumption contract which is used by consumers and this is defined by the service provider. when defining contract lots of teams decide to have the flexible contracts kind of flexible start and end dates beside some criteria and pagination data but the problem here is that if your consumer is a software there will be lots of hypotheses and that brings you some kind of inefficient service consumption.

If the consumer calls you in hourly manner demanding all data for last 3 days, this makes no sense in business value and this consumer gets 48 times the last item of D — 2. This kind of contract brings you some kind of inefficiency, A better approach will be to define Domain Events or Domain Requests based on your consumer needs so we can have the needs as Weekly , Daily, Hourly , Monthly.

So based on the Period kind received from consumer you generate the start and end date internally and this avoids unwanted scenarios. also helps you to observe the frequency of consumption of any kind of period.

The problem is that your consumers will need your action and evaluation of service behind their needs as a feedback .

Customer Life Cycle Care:

Caring about Customer / Consumers is a key point of Software design , we need to be able to solution the problem caring about peoples , behind people word i think about Sustainable solutions, less environment impact and minimal resource consumption but achieving the business goal.

Think about better solution where you manage well when a call need be done. Avoiding extra calls for nothing but something .

Personally i decouple the synchronous call letting my customer send me an event asking some data based on criteria, I do that and i will notify the consumer when the results are ready. This solution is a best solution in BFF word to improve customer experience on your User Interfaces using WebSocket for example,

Also in distributed services are alternatives kind of Receiving an Event via a broker Treating and publishing results via brokers, or calling a simple notify endpoint of your consumer saying call my service as there is something or no there is nothing.

My better approach is separate your consumers in to part

1. Who are periodical consumers
2. Who are per use consumers

The 1st category are interested about all their data and fetch them , so for theses kind of consumer it s a better approach to notify them where there something in your side so notify them and they will fetch the entities by ids you sent them in notify system

The 2nd category are the consumers per use case , kind of a BFF serving its front-end by data which are selected in UI by user here we can leave them be calling your sync api or serving them by a webhook kind system.

In this category we have also the batch consumers where they need their data per needs, so here receiving a Predefined Domain Event and serving back them by Push system or notify as the 1st category.

Inter-component Communication:

Improving solutions and modernizing solutions lead us to create lots of autonomous and single responsible components, this leads us as well toward inter-component communication challenges.

Ideally two systems communicate via a dedicated channel which is most of the time a call on the wire, but the important point to consider is how we manage that communication behind the scene.

A microservice without a broker or Queue is not a microservice

Adding a queue in your design let you have a layer of independent processing and isolate your internal state from other parts of the world without a direct impact. but managing the results and returning a value to the interested parties or components bring us some challenges where most of the time the consumers need evaluate their design, but that can bring us a lot of benefits in the future.

When bringing the Queues in our design basically we brings the notion of events where any event is an state over an entity in a domain bounded context.

I see most of the time the microservices share events and push them to the other components , this is great in term of design but in term of practice having N consumers of events who listen to theses events and evaluate their states by recalculating the event states is lots of duplicated work , any microservice will be responsible for evaluating the final state of an entity and notifying the consumers for that decision as well as keeping the event push system for the interested parties where they prefer be autonomous about you data.

Conclusion:

Taking care about a single part of business is not the business goal so designing a well single components which manage well its context is part of the game, but other is knowing a bit about what happening outside your domain to bring a business goal will help you to save lots of time and effort in the future.

Knowing and analysis of customer needs is ideally based on feedbacks but you provide a service and you must be a master of needs.

Transferring events all over the work just brings us a lot of mess and complexity. transferee the events with event states where needed but guaranty well the definitive result of an entity is your responsibility not consumers.

Contracts are your and are based on your knowledge about domain so try to evaluate your knowledge and make your self deciding contracts as a collaborative decision with your consumers interactively and consider thinking about feedbacks.

Doing mess is easy and is not avoidable in any team but capturing that your are going to design a mess is more important than what you did, so capture , do analysis and bring the action to avoid redesigning un-necessary complexities in your design.

Wish you enjoy the reading