1

I do system integration for critical and time sensitive systems. We have two standard ways we can build these system integrations. One is a simple (and cheap) email ingestion tool built into our platform and the other is a very customized (expensive) standalone HTTPS Restful API integration.

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it.

  • 2
  • 3
    Carefully explain the pros and cons from his perspective, and then let him make the decision. – Robert Harvey Sep 1 '16 at 17:51
  • 3
    Can they afford the expensive solution? or Can they afford NOT to build the expensive solution? – Tulains Córdova Sep 1 '16 at 17:54
  • 2
    Please don't take the fact that I bothered to answer this question as an endorsement of the way it was asked. I'm looking past the off topic "how to explain x to y" issue and pointing out that there is a design decision to make here. Framing your question this way won't get us to come down on your side. Learn your customers needs and tell us about them. Then you'll get better answers here. Feel free to use the "edit" link. – candied_orange Sep 1 '16 at 18:24
  • Looks like @TulainsCórdova is trying to help you with a another question: What is email ingestion and are there modern uses for that technology? – candied_orange Sep 1 '16 at 18:38
8

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it.

By knowing why it's not.

Name one real need that the email solution can't solve.

I can guess at a few. HTTPS is fairly good at securely communicating and proving you're talking to who you think you're talking to. But are those real needs for your customer?

Customers are usually easy to convince that you know how to do what you want to do. I'm already convinced you know how to make a Restful API and I don't even know you.

What I don't know is that you really understand your customers needs. If you're trying to talk them out of using email there must be some reason they favor it. Maybe they've used it before. Maybe they understand it enough to trust it and somewhat maintain it. If you switch them to REST what are you taking away from them?

I've worked in systems that use email exactly the way your customer is describing. It feels like it's held together with bailing wire. But it can work.

Even manual email can be critical and time sensitive. People use it for that anyway. Sure your customer doesn't have other needs that an API works better for than an email parser? Maybe talk about those.

3

I agree with everything CandiedOrange mentioned (including the how to explain x to y comment). It's all about the clients needs. I've built systems that rely on smtp email. It works fine and it suited the clients needs. And as far as I know it still runs, even now 7 years later.

However, there is one downside here, as I see it. And it's the response.

In a http request the response is given directly. Unless it's using fire and forget, but let's keep that aside for now as most restful services don't. The caller can immediately know if the receiver got the call. That is not really possible (as far as I know) with SMTP. This way you can handle errors in the communication faster with http(s).

So, in theory, the caller should be able to get a confirmation from the receiver faster (read: directly) if you're using http(s) than with SMTP. However, there's really no guarantee that a http request will be faster than smtp.

Another thing to consider is the dependency to the mailserver, eg. Exchange. What if it goes down or has to restart? If the two systems only depend on each other there's one less thing to worry about when applying updates and considering downtime.

1

You don't!

You just make sure the client is aware of the distinctions:

Email is more inherently optimistic, and it's more inherently asynchronous. When the client sends a message, it assumes the recipient receives and processes it. Failures aren't necessarily reported. And those failures that are reported aren't always even reported back to the sender. And they sometimes can't be -- like if the sender uses a black-hole return-to address.

On the contrary, because HTTP is designed for document fetching, API's that run over HTTP can and generally do respond immediately with detailed success codes and messages directly to client. And while asynchronous message processing is still an option here, it's much more in-line with HTTP for clients to receive immediate success/fail operations if those are needed.

There may be other important things to point out. One of those might be, "I can develop REST API's faster, b/c it's what I normally do." And those points aren't invalid. But, they're not technical reasons. They're practical realities.

But, that's basically it. If you're competent enough to work it either way, you mostly just need to decide with the client whether the integration needs immediate failure processing, or whether the client-machine(s) can safely ignore errors.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.