4 posts tagged with "microservices"

Functional Programming Isn't Just for Academics — Part 22

I have asked all of my neighbors to call the fire department if they see smoke billowing out of my house. If they send too many trucks because too many called, my neighbors will have something to laugh about while they watch my house burn down. We probably do not want them sending all the trucks to one side of town in case a fire breaks out elsewhere, or shelling out more diesel than they need to rolling unneeded trucks, but as a homeowner, I do not worry about idempotency. That is the fire department's problem.

Redundancy, fail-over, redelivery, supervision, automatic retry: each of them exists so that when something goes wrong the work still happens, and the way each of them accomplishes that is by attempting it another time. A system that reroutes around a dead node, redelivers an unacknowledged message, and replays an interrupted job is a system that does important things more than once. Not as a malfunction. On purpose, as a sign of health. Every mechanism you bought to keep work from being lost is a mechanism for doing it again. Which means the better your infrastructure gets, the more correctness you owe your model.

When a customer is charged twice on your system and your infrastructure, you go looking for the broken thing, and you may not find one. The queue delivered the message. The worker that crashed mid-charge was restarted by its supervisor in under a second, exactly as designed, and the restarted worker did what it was told: it charged the card. Every recovery mechanism worked. The transaction is what failed. Every component behaved the way you paid for it to behave. The second charge is not the price of a fragile system. It is the price of a robust one.

Functional Programming Isn't Just for Academics — Part 17

You send a command to unlock a door; not a metaphor, an actual lock, on an actual door, opened over the network because a tenant is standing outside it and your service has decided to let them in. The command goes out. Somewhere between your server and the lock a packet is lost — not the command, the acknowledgment. The lock opened. The confirmation never came back. From where your code stands, the operation has no result. The safest-looking move, the one every retry policy in the world will make, is to send the command again.

Whether that second command is harmless or a small disaster was decided long ago, not by the network, but by whoever modeled the operation. And the same question hides inside far more than the state of a lock. Provision a server, and a lost reply means you pay for two. Issue a customer the license they bought, dispatch a shipment, send a notification, publish a post, grant a permission… Every one is the same operation: an effect that leaves your control and cannot be pulled back, reached across a channel that can lose the receipt.

If your commerce platform drives critical revenue and the services it provides are difficult to predict in nature or scale — or if optimizing user experience depends on near-real-time responses to changing signals — reactive commerce warrants attention. Reactive commerce orchestrates digital discovery, selling, purchasing, and merchandising while adhering to the Reactive Manifesto's principles.

I'm a big fan of service oriented front-end design and microservice based architectures. If I were building a new service to take to market, I'd most likely go that way. Certainly, I would design it cloud native and my MVP would be API-first… After all, why would I invest the effort of building a slick UI when everyone is so gaga to go headless? But, as a purveyor of digital commerce, would I redeploy my front-end to take advantage of headless design or rearchitect my back-end to leverage all the advantages of a microservice architecture? Probably not.