IDEALS for Microservice Design

Friday afternoon 14:00 - 16:00 CET (UTC+1)


Paulo Merson and Joseph Yoder


It’s been seven years since we’ve started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, there’s the five SOLID principles. For designing microservice-based solutions, we propose developers follow the “IDEALS”:

(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.

(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.

(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call.

(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they’re okay with eventual consistency.

(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.

(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.

We will discuss how these IDEALS can be realized using different patterns, techniques, and tools to create microservice architectures.

In the practice part of the session, you will create a design solution to a given problem, choosing patterns we discussed, and pondering about the tradeoffs.

About Paulo Merson

Getting wiser but remaining silly Twitter LinkedIn

Paulo Merson has been programming in the small and programming in the large for over 30 years. He is a software developer at the Brazilian Federal Court of Accounts. He is also a Visiting Scientist with the Software Engineering Institute (SEI), a certified instructor for Arcitura, and a faculty member of the master program in Applied Computing at University of Brasilia. Paulo often delivers professional training to fellow developers in the United States, Latin America, and Europe. His speaking experience also includes tutorials at JavaOne, SPLASH/OOPSLA, SD Best Practices, SATURN, Dr. Dobb’s Architecture & Design World, The SOA and Cloud Symposium, lectures to graduate students in different universities, and invited talks at different companies. He is co-author of Documenting Software Architectures: Views and Beyond, 2nd edition. Paulo holds a Bachelor of Science in Computer Science from University of Brasilia and a Master of Software Engineering from Carnegie Mellon University.

About Joseph Yoder

The Refactory - MetaYoda Twitter LinkedIn Company Website

Joseph (Joe) Yoder (agilist, computer scientist, speaker, and pattern author) is the founder and principal of The Refactory (, a company focused on software architecture, design, implementation, consulting, and mentoring on all facets of software development. Joe is also the president of The Hillside Group (, a non-profit dedicated to improving the quality of life of everyone who uses, builds, and encounters software systems. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences. He is best known as an author of the Big Ball of Mud pattern, which illuminates many fallacies in software architecture. Joe teaches and mentors developers on Agile and lean practices, architecture, building flexible systems, clean design, patterns, refactoring, and testing. Recently Joe has been working with organizations and thought leaders on the best practices for including quality aspects throughout the complete software life-cycle. Joe thinks software is still too hard to change and wants to do something about this. He believes by using good practices (patterns), putting the ability to change software into the hands of the people with the knowledge to change it, and bringing the business side closer to the development process helps solve this problem.