![]() ![]() If your clients are external, then moving your customers onto the non-deprecated feature could take years. Fixing your technical debt often requires your callers to change. Removing ssn prior to that would break the upstream services and cause the product to lose service. But you are stuck with ssn as a parameter until the last caller switches to using id. This gives them a migration path off of the API. Your upstream micros can then invoke you either using ssn or id. The best you can do is allow it to optionally take in a second field called id like the following: HTTP GET /users?ssn=333-33-3333&id=abcde-fghi-jklmnopq ![]() The API is used by nearly every other micro. The decision is made to remove it as quickly as possible.īut you can’t remove it immediately. In fact, a compliance agency threatens to remove one of your certifications when they discover this API. For instance, you own the user service and have an API for retrieving a user by social security number that is invoked over HTTP like the following: HTTP GET /users?ssn=333-33-3333Ī few years after your product launch, your leadership realizes that querying for user data by social security number is a bad idea. For one, you MUST never break your callers/upstreams (except under rare circumstances like an active breach in which case it might be necessary). The issue for downstreams is that changing the interface is hard. The User/Tenants service in the above diagrams serves as our example. The Downstream Problemīy downstream I mean services that are late in the call flow. However, Business Logic 2 team does not adopt it because they already have the functionality they need. Search builds the search functionality for user data. Months later, the Search to finally is able to get the data they need from the Users/tenants team. To make matters worse, Business Logic 2 service decides to invoke Business Logic 1 to search user data because the functionality is ready. ![]() Business Logic 1 finds a way to maintain a list of users, so instead of using the Search team, they use their own data. However, Business Logic 1 service needs this functionality. Thus, the Search team cannot provide search functionality containing user data. This is often necessary, but it is problematic because it has potential to create technical debt that is difficult to unwind because micros end up having functionality built into them that logically should be elsewhere.įor example, what would happen if the Users/Tenants team failed to deliver their data to the Search team. However, if the downstream team is unable to provide the needed functionality in a timely manner, then the upstream might i mplement it themselves or find a clunky workaround. This creates overhead in that leadership and the two teams need to negotiate priority. Why? Usually, this is because those services are owned by other teams which have differing priorities from your team. The issue for upstream services is that downstream micros often do not yet provide sufficient APIs to enable your features. User/tenant management is probably fifth. The client (frontend/Web browser) is the most upstream on this diagram (the client isn’t a micro though). By upstreams I mean services that are early in the call flow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |