Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Living without REST: Event-Driven Architecture

Living without REST: Event-Driven Architecture

We got it: everybody knows how to create that pretty REST endpoint for your Microservices architecture. But even though REST over HTTP represents an important part of this whole new API world, most of the backend enterprise communications should be implemented using an Event-Driven Architecture on top of a Message-Driven Architecture.

Most developers got used to a request/reply mindset, and great technologies like traditional message brokers lost the spotlight. Basically because these developers believe that messaging is "hard". Join us on this session and we'll convince you that messaging is not hard: it's just not understood. And instead of adding a ton of code to control our fallbacks, tracing etc we can leverage tools like ActiveMQ, Kafka and Camel to create distributed, resilient, and performant Microservices architectures. Do you think that the code for doing this is clunky? Well, we'll prove otherwise.

Edson Yanaga

April 25, 2019
Tweet

More Decks by Edson Yanaga

Other Decks in Technology

Transcript

  1. Edson Yanaga @yanaga - Follow: - With a picture of

    the session - Mention @yanaga - With hashtag #fullstackporto Raffle Rules
  2. Join developers.redhat.com 18 ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001

    1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions
  3. Join developers.redhat.com 23 ID NAME PHONE ADDRESS BIRTH 1 Burr

    222-222-2323 901 South St 12/12/1968 2 Edson 222-333-3434 112 North Dr 03/03/1978 3 John 111-456-4545 666 Iron St 06/06/1966 4 Doe 333-789-7890 777 Boeing Dr 07/07/1977 INSERT INTO CUSTOMER(ID,NAME,PHONE,ADDRESS,BIRTH); SELECT * FROM CUSTOMER;
  4. Join developers.redhat.com 26 SELECT ID, NAME, AGE, AVG_BILL FROM CUSTOMER_REPORT_VIEW;

    SELECT ID, PHONE, LAST_PAYMENT_AMOUNT FROM CUSTOMER_BILLING_VIEW;
  5. Join developers.redhat.com 28 ID CUSTOMER_ID BALANCE 1001 990 1000 1002

    991 0 1003 991 -500 1004 992 300 Account ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001 1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions
  6. Join developers.redhat.com 29 ID CUSTOMER_ID BALANCE 1001 990 1000 1002

    991 0 1003 991 -500 1004 992 300 Account ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001 1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions READ MODEL WRITE MODEL