Consider a vanilla CMS: Public site where random visitors can view, with an admin part where groups of privileged users can log into and create&#x2F;edit articles. In a microservice world, I would (and have) split this like so:<p>* Front end: Perhaps a basic Node.js or Rails app. It&#x27;s UI only; all data handling is done through APIs to the backends.<p>* Admin: Completely separate app. Same here, UI only.<p>* Post backend. This is a data store for articles. It has APIs for creating, updating, deleting articles. It also has a permission system that connects users to the groups that they are part of. This could be a separate microservice, but it&#x27;s natural to keep it close to the data (also for performance reasons, since every post lookup needs to check if the calling user is allowed to see it).<p>* Login backend. This has a user database and can do things like accept logins via other services such as Google and Twitter, via OAuth.<p>* Miscellaneus support services. For example, say you want to support upload images: Make it a microservice that calls into ImageMagick and stores stuff in S3. Or let&#x27;s say you want to support importing WordPress exports (WXR archives). Make it a service that parses and uploads asynchronously to the post backend.<p>I have built this as a monolith, and as a microservice system. The microservice platform is much more flexible and clean.<p>It also allows us to reuse every part for other apps — and this is in my mind the number one benefit that microservices gives you. We&#x27;ve had several new projects completely unrelated to what we&#x27;ve built before, and we have simply reused the microservices we had already created, only swapping out the new front end.<p>Making reusable microservices is an interesting challenge, since core concepts (things like users and data objects) need to be generalized, and mechanisms built in so that you can make specific features that don&#x27;t burden the microservices with too many conflicting concerns. For example, let&#x27;s say that your CMS&#x27;s public site wants users to be able to &quot;like&quot; individual articles. Instead of building this into the article store, create a microservice which abstracts the concept of &quot;liking&quot;. Or let&#x27;s say you want users to sign up for a newsletter version of the site that sends them a digest every week; again, don&#x27;t build it in, but make a microservice that abstracts this into &quot;subscriptions&quot;, with a registry of emails and what users are subscribing to, and so on. To generate well-formatted emails, simply let the front end provide an API for rendering templates, which this &quot;subscription&quot; microservice can invoke to do the actual rendering. Generalizing it this way makes it easy to then create new types of subscriptions, such as SMS messaging.<p>Another important point is that every microservice has to be multitenant; a single microservice can host multiple unrelated datasets, and they need to be partitioned in a way that allows the APIs to not comingle the data by accident. It&#x27;s not rocket science, but it takes some planning and practice to make the APIs feel natural.