Hacker News Reader

Comment by simonw | Hacker News Reader

I kind of feel like the moment you're trying to run a transaction across data stored in multiple separate microservices, you're in trouble.

"Can entirely encapsulate a transaction" is a good rule of thumb for designing your microservice boundaries.

Once that transaction has completed within the microservice, you can have other services then reliably carry out follow-on actions (maybe via an at-least-once delivery queue such as Kafka).

View on HN

I kind of feel that every single person that has had good experiences with microservices actually experienced something that doesn't fit the "micro" description, and often enough not even "service".

If the thing can encapsulate an entire transaction, then it's taking care of an entire business vertical. What I do agree, it's one of the best ways to partition your services (just after not doing it). But calling this a "microservice" only serves to confuse people.

Yeah can't we just have services without making them tiny. Just because I don't think having 7 services is an appropriate architecture for a team of 3 doesn't mean I don't think it's an appropriate architecture for a team of 100.

It has always been that except for the constant onslaught of misinformed idiots who have no clue about architecture (especially here on hackernews) trying to convince people otherwise.

Or get the project approved. Sometimes you dont work with reasonable people: they want micro services, they cannot forgive you for doing one and then not having transactional correctness. So you have to call your business service a micro service, a small lie that saves a lot of pain and money.

It's like finishing a migration by renaming your initial project with the new name of the target project: everyone is happy, the software is still working, the various political stakeholders now feel the warm embrace of ownership from the old bad domain to their turf, and you saved years of reinventing the wheel to end up in the same place.

Transaction usually refers to the atomic but of what needs to be done which is certainly not guaranteed to be a business vertical.

You should never have a microservice that doesn't own something unique and the best ones are interesting enough to have a proper owner.

Is it the word micro that causes the issue? Services are way easier and more logical when they are verticals - this is how it's largely meant to be. How many people have read the supporting books and literature that say as much? That would be a good question.

Almost everywhere you go, you see the same mistakes. Almost every one can be found in Sam Newman's 2nd edition. The conclusion I draw is that a very large number of developers ran with it without understanding the pros and cons. Services are only worth it if your organization benefits more from the pros. Many orgs don't, so it makes no sense for them to adopt it over monolithic architecture that is way easier to implement transactions with.

Designing "transactions" across services and databases is an insane endeavour. It's best if each service is split on a line that it can deal with incomplete states in other services.

> Is it the word micro that causes the issue? Services are way easier and more logical when they are verticals

I think that the word micro is indeed the issue. Once they stop being micro and just become services, it pretty much becomes a Service Oriented Architecture. So why keep calling it microservices?

The "micro" was specifically coined to mean breaking a vertical into several smaller services. So, if you go look online how to create microservices, you will get most of the material biased into that. Even though most people pushing those describe something saner, what the docs say is what you will get.

Before that, we had "SOA", that was coined to mean exactly breaking your system into full verticals. But then the term was hijacked by some very loud companies selling tools for microservices, and now if you go search for it you will mostly find stuff like how to set distributed transactions.

Overall, humanity currently has a pretty hard time communicating, due to the sheer number and size of bad actors actively and purposefully polluting our communication infrastructure. We get to feel the effects when talking about software too.

This is the correct answer, and it only took three sentences and nary a diagram to state. Well done!

I kind of feel it depends on what does "transaction" mean to you. In a multiple steps business flow, one can say each step is a transaction, but people also treat the whole flow as a transaction. For example, a user buys a product online and pays by her bank card. It could be implemented as following steps: 1. sales services request inventory service to reserve a product for this user. 2. sales service request payment service to debit user's card. Is reserving a product a transaction by itself? Or is it just a step of a bigger transaction of buying? If you take the former, then cancelling resevation would be another transaction. If you take the later, then cancelling reservation is a part of transaction rolling back.

For me, the word "transaction" means a thing where you want to store data in your database is a single unit, where it either all succeeds or it all fails.

A multiple business step flow should be called something different, to avoid confusion with well established database terminology.

What cannot the client forgive you for not ensuring: I faced this case, we had an ivory tower-designed micro service architecture, the travel insurance team decided to use it to not be fired or humiliated by the architect 2 floors above.

They proceed to create 5 services in python aws lambdas: ui proxy, credit card processor, insurance gateway, email service.

The flow would be: the user clicks buys, it sends the the ui proxy, which triggers a redirect to a credit card ui, the client pays, the backend sends a request to the insurance gateway, and if all goes well, an email is sent with the policy.

Ofc, we didnt receive a policy document from the insurance gateway, we'd generate it ourselves on success, the insurance gateway only saying "ok". The first few weeks, the team missed some failure condition on the insurance gateway, and would charge the client and send a policy pdf by email, but the client was NOT actually insured. It impacted 7 clients a day going to trips thinking they were insured but were NOT.

Imagine the face of the business when they realized there was no transactional boundary over the whole process: one micro service could fail and the others could succeed and god knows what happens then. The change was to build one giant procedural thing that does 1 step at a time and finishes once all is good. One service, one transaction, one state that matters. The architect was eventually fired, finally.

Hmm, wouldn’t things have ended up the same inconsistent state if you had it all built as a single service in the first place? E.g. you still can miss a failure condition on the insurance side and end up with a committed transaction? Why was the failure missed in your opinion? Was it because of the opaqueness of the services?

If you go monolith, you’ll of course have the advantage of having one place that orchestrates everything, the place where you start the transaction and follow up with credit card / insurance / email.

But if you are forced to deal with micro services you can roll a poor man’s transaction in the form of a state machine for the whole process backed in the db. Ui proxy receives click, credit card service authorizes money, insurance generates, credit card service settles transaction, email is sent.

The good thing about this whole affair is that you can very clearly see where something fails and why, because failure is not a special case, but part of the normal operation of the service. Also gets you the whole split up into micro services thing where different teams can handle different services. Bad thing of course is its massively more complex, so most probably is not justified.

Transactions are great, but when they rollback, they rollback everything. Now if you want to actually understand and track what went wrong, you need to log stuff somewhere else, which in itself can also fail.

The important question tends to be what happens when things go wrong, such as losing a database and restoring it from backup.

Your database and the credit card company's are separate, so they may retain a record even if you lost the data.

I agree with you, but, I once responded along these lines in an interview and it's not what people want to hear.

What did they want to hear?

I'd imagine something like the saga pattern, what it is, how you use it, when you would use it, etc. would be a decent response

Business doesn't work that way.

Every business I've ever worked for has figured out they have peanut butter down, and they have chocolate pretty well squared away, and wouldn't it be great if we made peanut butter cups? We have all the bits we just need to mash them together.

Business loves, loves, loves creating new features by combining existing ones. It's easier than actually inventing anything new. So whatever transactional boundaries you created two years ago? Those are creaking under the weight of feature factory work coming in from customers, business folks and the C-suite.

That you even consider a "peanut butter" microservice demonstrates your total lack of knowledge about them. "Peanut butter" is not a business capability, it is an entity. If you try to align services with entities, you are designing a data model, not a microservice architecture and it is inevitable that you will have a mess where any change needs data from a dozen services and business logic is stretched equally thin.

It was a metaphor. They always want to tie the display of one piece of data they’ve gathered with some other piece of day they gathered separately. And they eventually come around to the idea that they want it to be consistent. So now your two concepts that were separate are part of some feature that correlates them.

I kind of feel like as soon as you decide you need transactions at all you've probably gone off the rails already. Many cases where people believe they need transactions actually just call for doing things in a defined order, or sometimes even just chaos. People jump straight to transactions without thinking through the real minimal constraints.

Reply on news.ycombinator.com