DEV Community

Zain Ahmed
Zain Ahmed

Posted on


Overview of My Submission

So basically I was exploring the concept of Microservices few days back ago to learn about how we can achieve the Microservice architecture for large scale applications and how we can reduce the dependences of multiple modules on one another and in a mean time I found out about Appwrite tool which is really helpful for backend services so I decide to explore it and found out that i can host my Microservice server to Appwrite with all features like authentication, encryption, predefine functions etc. My main concept of the submission is to divide the server in microservice module so that is any module break\no available user can still do some actions on website\app so their will be no restrictions or any performance issue.

My project is still in under development

Submission Category:

Wacky Wildcards

Link to Code

GitHub logo zaahmed-nisum-com / microservice-servers

I have create Micro Services server for chatting application using node js


I have create Micro Services server for chatting application using node js

Auth server Chat server Notification server

Additional Resources / Info

Postman for API's testing

Top comments (2)

ievolved profile image
Shawn Bullock

I've done a lot of fault tolerant stuff that scales to billions of users. A very high level way to achieve this, is something like:

The app with a default action if the API doesn't work

The end point of the app with a default action if its deeper actions don't work

Scale more servers/instances if needed, use a great reverse-proxy or API gateway scheme

It's okay to use macro services (instead of a micro server per every granularity -- an approach I call NanoServices because there's so many, you'd share a few related features together)

You don't really have to have a different database per micro service. You can use a monolithic data approach just make sure no two services acto on the same data in the same way. Were that the case, do cross service calls

It's okay to have higher level services that act as orchestrators to avoid cross-service communication

If you really need a lot of cross service communication, using a ServiceBus or Event-Driven architecture will help you.

The more microservices the more maddening it'll be maintaining them without a very good DevOps/automation strategy. Because of this we took more of a macro service architecture than a micro/nano service on. Now that we have all the automation, we're breaking each controller into a microservice as it should be. Prologinging this step has saved us a lot of pain.

Keep it as simple as possible.

For faul tolerance, that really only works if you have a failover system, a way to get to an alternate behavior, or a way to avoid a non-essential behavior. It's easier to start with a default alternate behavior (in the app, then in the service) then a scale up/failover in the DevOps side. That way you can get some reliability and time to do the hard stuff.

zainbinfurqan profile image
Zain Ahmed

Thank man for deep explanation.❤️❤️❤️