Hi, we are AppUnite, we take care of the businesses from a tech perspective. We build products and teams around them enabling our clients to bring the difference to the world.

We believe in knowledge sharing and software as a tool to improve companies and peoples’ lives. We take lessons from our daily challenges and share that experience and knowledge to help you build better products. 

Let’s talk about products, businesses, and software development!

Event-driven architecture is a powerful idea. It allows the system to grow and evolve in a loosely coupled manner. The concept of separating a business fact from its secondary consequences brings a lot of flexibility to the table and allows teams to work efficiently even in a substantially complex environment.

At AppUnite, we use it a lot these days. But every coin has two sides. One thing that you need to tackle among others, when you decide to embrace that approach, is the message delivery guarantee. In terms of that, you can pick **at most once delivery** or **at least once delivery**.

The former doesn’t ensure that a message will be delivered at all, but it also doesn’t produce duplicates. On the other hand, delivery of the latter is guaranteed, but you need to cope with processing the same message many times. Practically, in most business domains, we can’t afford to lose a message. For instance, can you imagine that a banking system would lose a message concerning your paycheck? You probably would not use it again. Thus, in most cases, **at least once delivery** is the way to go.

But then… how can we deal with these duplicates? Receiving a paycheck twice wouldn’t be a bad thing, but being charged twice for your Netflix subscription is definitely not cool! In this blog post, I want to share with you a few typical use-cases along with possible solutions. We are going to use that "Netflix-like-system" example as the groundwork for our discussion. So, let's find out what challenges we could expect in such a domain.

## Rolling up our sleeves
Following the terrifying example with a single subscription being charged several times, let’s sketch out a technical overview. Imagine that this requirement is being fulfilled in the system by two contexts, which cooperate. **Subscriptions**, which is responsible for holding subscription details, recurring logic and so on, and **Billing** which takes care about payment methods and processing billing entries. When a subscription is prolonged for the next period, Subscriptions context publishes an event:
```elixir
%Event.SubscriptionProlonged{
  event_id: "66877e92-aeec-4490-9fd8-b69546797c16",
  subscription_id: "ad5a6c02-819d-4649-b364-e236c2cdd5b7",
  product_id: "90a501c6-535e-4495-931e-2b38fc761417",
  subscriber_id: "b605825e-5c9e-49ff-be2f-81226c2a1132",
  months_prolonged: 1, 
  ends_at: ~U[2021-06-09 14:15:22.446671Z]
}
```

After that instance has taken place, the system needs to charge an adequate fee corresponding to the chosen product and given period. How can we achieve that without draining our dear users’ bank accounts to zero?

Assuming that you have a RDBMS under the hood, you can leverage an **unique index**. It prevents you from inserting an already existing record. What is worth noting is that the condition is evaluated at the database level, so the code is safe in terms of concurrent access.

So, probably, we would have some code that will be responsible for receiving an event and passing it down to the business models. It could look like this:
```elixir
defmodule Billing.Entry do
  use Ecto.Schema

  @primary_key {:id, :binary_id, autogenerate: true}
  schema "billing_entries" do
    field :payer_id, :binary_id
    field :amount_cents, :integer

    timestamps()
  end
end

defmodule Billing.Consumer do
  # Event subscription logic skipped
  @interested_in [Event.SubscriptionProlonged]
  
  def handle_event(%Event.SubscriptionProlonged{} = e) do
    Billing.Service.register_payment(
      e.event_id,
      e.subscriber_id,
      e.product_id,
      e.months_prolonged
    ) 
  end
end

defmodule Billing.Service do
  # Arguments validation skipped for the sake of simplicity
  def register_entry(entry_id, payer_id, product_id, months_billed) do
    amount_billed = Billing.Pricing.calculate(product_id, months_billed)

    billing_entry = %Billing.Entry{
       id: entry_id,
       payer_id: payer_id,
       amount: amount_billed
     } 
     
    {:ok, _} = Repo.insert(
       billing_entry, 
       on_conflict: :nothing, 
       conflict_target: :payment_id
     )
 
    :ok			
  end
end
```

## Relevance of the idempotency
As you can see the `Billing.Service.register_entry/4` always returns atom `:ok`. No matter how many times we invoke it, the result will be recorded only once. This trait is called **idempotency**. It's naturally connected with **read** operations (asking the question should not change the answer), but thanks to setting a proper unique index, we can also achieve it on the **write** side. In this case, the puzzle was about choosing proper data for a **primary key**, event_id is exactly what we need here. And we can see that it gets along well with our previous decision - picking at least once guarantee.

Speaking of idempotency of writes. It is an important quality of the `Billing.Service`. We should highlight this trait and leave some information about it in the code.  A unit test would be a good place for that.
```elixir
 defmodule Billing.ServiceTest do
  use Repo.DataCase
  import Ecto.Query
  
  test "registers entry idempotently" do
    entry_id = random_uuid()
    payer_id = random_uuid()
    product_id = random_uuid()
    months_billed = 1

    subject = fn ->
      Billing.Service.register_entry(
        entry_id, 
        payer_id, 
        product_id, 
        months_billed
      )
    end	

    assert :ok = subject.()
    assert :ok = subject.()
   
    assert [%Billing.Entry{
      id: ^entry_id
      payer_id: ^payer_id
    }] = Billing.Entry |> where([e], e.id == ^entry_id) |> Repo.all()
  end 
end
```

## Summary
So, let's quickly sum up what we have achieved here. We have implemented a specific business scenario, which spans across two possibly separate parts of software, in the way that respects their autonomy. We can easily imagine that these two parts can be deployed as separate systems. We have leveraged the RDBMS built-in mechanism in order to provide idempotency at our interface and ensure that we won't violate any business requirements. This certainty has also been materialized in the test case.

Of course, integrating parts of a software asynchronously with events is a big matter. Stay tuned and expect deeper exploration with slippery cases in the future!




Paycheck, events, idempotency and elixir - what do they have in common?

large_paycheck-events-idempotency-and-elixir-jonas-leupe-unsplash.jpg

medium_paycheck-events-idempotency-and-elixir-jonas-leupe-unsplash.jpg

small_paycheck-events-idempotency-and-elixir-jonas-leupe-unsplash.jpg

thumbnail_paycheck-events-idempotency-and-elixir-jonas-leupe-unsplash.jpg

paycheck-events-idempotency-and-elixir-jonas-leupe-unsplash.jpg

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/afff94b6-4563-4d94-b4ff-8774df032916.png

Still wondering what paycheck, events, idempotency and Elixir have in common? Here’s a specific business scenario, which explains it all.

Still wondering what paycheck, events, idempotency and Elixir have in common?  Here’s a specific business scenario, which explains it all.

Paycheck, events, idempotency and Elixir - what do they have in common? | AppUnite Blog

Paycheck, events, idempotency and Elixir - what do they have in common?

The coastline paradox had been first observed by Lewis Fry Richardson and later expanded upon by [Benoit Mandelbrot in Science Magazine in 1967](https://science.sciencemag.org/content/156/3775/636.abstract). It shows that measuring the coastline length is not as straightforward as it might seem. If you measure it using a very rough satellite image, you’ll get a much smaller value than in the case of very precise images. This is because the latter will provide you with more details to be taken into account. But let’s skip the theoretical considerations regarding this dilemma and focus on practical reasons for measuring the coastline length. These may include a road trip along the coast or sailing from one port to another. What we would find useful and practical in such circumstances are the measurements done by 14th-century cartographers, rather than subatomic-level surveys that would inevitably give much larger values.

You’re probably wondering why I’m deliberating coastlines at all. That is a software engineering article, after all. But I have my well-grounded reasons, I assure you. Just keep on reading!

The same principles apply to software development. When you’re working on a problem, you should look at it from a user’s perspective. 
If you look too closely, you might waste time and effort on details that are irrelevant to your users and that might even cause new problems. For instance, you can have a button that is pixel-perfect in design and implementation. But its placement is completely wrong and users won’t notice it and will miss on some important features. You might ask: “But isn’t it our ultimate goal to create perfect features?” Sure! However, attention to details without looking at the whole picture entails certain risks. You might spend so much time refining your feature that your competitors will deliver it sooner. Delving into irrelevant details might cost you missing the opportunity to launch a product at the best possible moment.

So if we, software engineers, can learn something from the coastline paradox, this is it: never lose sight of the bigger picture, as it really helps you make the right decisions.

large_Coastline Paradox.jpg

medium_Coastline Paradox.jpg

small_Coastline Paradox.jpg

thumbnail_Coastline Paradox.jpg

Coastline Paradox.jpg

https://strapi-appunite.s3.eu-central-1.amazonaws.com/covers-with-text/8c536c62-9250-4456-bb80-df457a317ebd.png

Get to know, what is the coastline paradox and how software engineers can learn from it.

Damian Kasperski

Problems for teams with only senior developers