<li>It doesn’t share database tables with another service</li><li>It has a minimal amount of database tables</li><li>It’s thoughtfully stateful or stateless</li><li>Its data availability needs are accounted for</li><li>It’s a single source of truth</li>

a well designed microservice

<div>
<h3>Characteristics of a well-designed service</h3>
<p>If you've read about microservices, you've no doubt come across advice on what makes a well-designed service. Simply put: high cohesion and loose coupling.</p>
<p>While sound advice, these concepts are quite abstract. I've spoken with dozens of CTO's on this topic to learn from them on how they've drawn their microservice boundaries, and I've distilled down some of the underlying characteristics for you below.</p>
<h3>Characteristic 1: A well-designed service doesn't share database tables with another service</h3>
<p>As we saw in Chris McFadden's case mentioned earlier, when it comes to designing microservices, if you have multiple services referencing the same table, that's a red flag as it likely means your DB is a source of coupling.</p>
<p>It is really about how the service relates to the data, which is exactly what Oleksiy Kovrin, Head of Swiftype SRE, Elastic, told me:</p>
<p>"One of the main foundational principles we use when developing new services is that they should not cross database boundaries. Each service should rely on its own set of underlying data stores. This allows us to centralize access controls, audit logging, caching logic, et cetera," he said.</p>
<p>Kovyrin went on to explain that if a subset of your database tables, "have no or very little connections to the rest of the dataset, it is a strong signal that component could be isolated into a separate API or a separate service."</p>
<h3>Characteristic 2: A well-designed service has a minimal amount of database tables</h3>
<p>The ideal size of a microservice is to be small enough, but no smaller. And the same goes for the number of database tables per service.</p>
<p>Steven Czerwinski, Head of Engineering, Scaylr, explained to me during an interview that the sweet spot for Scaylr is, "one or two database tables for a service."</p>
<p>"We have a suppression microservices, and it handles, keeps track of, millions and billions of entries around suppressions but it's all very focused just around suppression so there's really only one or two tables there. The same goes for other services like webhooks" explained Chris McFadden.</p>
<h3>Characteristic 3: A well-designed service is thoughtfully stateful or stateless</h3>
<p>When designing your microservice, you need to ask yourself whether it requires access to a database or is it going to be a stateless service processing terabytes of data like emails or logs. Be clear about this upfront and it will lead to a better designed service.</p>
<h3>Characteristic 4: A well-designed service has its data availability needs accounted for</h3>
<p>When designing a microservice, you need to keep in mind what services will rely on this new service and what's the system-wide impact if that data becomes unavailable. Taking that into account allows you properly design data backup and recovery systems for this service.</p>
<p>When speaking to Steven Czerwinski, he mentioned their critical customer row space mapping data is replicated and separated in different ways due to its importance.</p>
<p>"Whereas the per shard information, that's in its own little partition. It sucks if it goes down because that portion of the customer population is not going to have their logs available, but it's only impacting 5 percent of the customers rather than 100 percent of the customers," Czerwinski explained.</p>
<h3>Characteristic 5: A well-designed service is a single source of truth</h3>
<p>The final characteristic to keep in mind is to design a service to be the single source of truth for something in your system.</p>
<p>To give you an example, when you order something from an eCommerce site, an order ID is generated. This order ID can be used by other services to query an Order service for complete information about the order. Using the pub/sub concept, the data that is passed around between services should either be the order ID, not the attributes/information of the order itself. Only the Order service has complete information and is the single source of truth for a given order.</p>
<h3>Is your service too small or not properly defined?</h3>
<p>Once you've applied the above characteristics, you should take a step back and determine whether the service you've created is too small or not properly defined.</p>
<p>During the testing and implementation phase of your microservice system, there are a number of indicators to keep in mind:</p>
<p><strong>Over-reliance between services</strong>. If two services are constantly calling back to one another, then that's a strong indication of coupling and a signal that they might be better off combined into one service.</p>
<p>Going back to the example Chris McFadden shared above where he had two API services, accounts and users, that were constantly communicating with one another, McFadden came up an idea to merge the services and decided to call it the Accuser's API. This turned out to be a fruitful strategy:</p>
<p>"What we started doing was eliminating these links [which were the] internal API calls between them. It's helped simplify the code." McFadden informed me.</p>
<strong>Does the overhead of setting up the service outweigh the benefit of having it be independent?</strong> <p>Darby Frey explained, "Every app needs to have its logs aggregated somewhere and needs to be monitored. You need to set up alerting for it. You need to have standard operating procedures and run books for when things break. You have to manage SSH access to that thing. There's a huge foundation of things that have to exist in order for an app to just run."</p>
</div>

If you've read about microservices, you've no doubt come across advice on what makes a well-designed service. Simply put: high cohesion and loose coupling. While sound advice, these concepts are quite abstract. I've spoken with dozens of CTO's on this topic to learn from them on how they've drawn their microservice boundaries, and I've distilled down some of the underlying characteristics for you below.

Microservice boundaries: five characteristics to guide your design

a well designed microservice

Bogdan Lucaciu's ideas are part of this journey:

Related collections

Similar ideas