Welcome to This Is My Architecture, I'm Francesco Marelli from AWS
and today I'm with Paolo Ferretti from MailUp Group.
- Hi Francesco. - Welcome Paolo, thanks.
- Thanks. - Would you like to tell us about MailUp Group?
Sure, MailUp Group deals with marketing technology
and it's an Italian company that is present all over the world.
We have branches in the US, Spain, The Netherlands and Denmark.
Great. Can you tell us about the features that you have implemented with the application
that you are introducing to us today?
Sure. The application that I'm going to talk about today is called Messaging API
and allows our clients to plan and send marketing campaigns
to applications of instant messaging.
Ok so we are talking about our clients' end clients. - Exactly.
...as the final users are our clients' end clients.
Perfect. Can you tell us more about the application flow?
Sure.
The main actors of this architecture are our MailUp clients
who access our application, which is a single-page application
- provided directly from a bucket S3... - Great.
...it can be accessed through CloudFront.
Our clients' end clients always access CloudFront
to get to our buckets S3 which contain the resources then displayed
- relevant to the marketing campaigns. - Excellent.
This single-page application
makes API calls to services
via a load balancer application.
These services are provided on a cluster ECS.
What kind of features have you implemented on the ECS cluster?
The ECS cluster has got different micro-services.
There is a first level of micro-services which has some APIs.
These services are mainly in charge of performing the user identification.
We have an authentication system called OAuth 2.
Then we have a service for managing bots,
so that it performs the actual messaging
towards the end client.
Then we have a service for url shortening
that allows all the links on our platform
to be shortened
and provides then statistics on the use
- on the events generated by these links. - Sure.
Finally, last but not least,
we have a service that manages webhook,
which are the events generated by the platform in real time.
Great, so I guess these events
are logged somewhere.
- Exactly. - Of course.
The events are logged, we have chosen a key-value store
- in our case is DynamoDB... - Great.
...which interacts directly with the services on the ECS cluster.
Then for other types of data
we use a RDS instance.
In our case we have chosen MySQL as a database.
And then we also use ElastiCache,
we have chosen a Redis cache.
Redis cache is an application cache.
- Yes. - To avoid overloading
- the database too much. - Great, excellent.
How do you manage the high reliabilty and the resilience of your application?
The high reliability is managed from the data point of view,
through a RDS Multi-AZ instance.
While from the cluster point of view
we have a configuration that ensures
that there is at least one EC2 instance on each availability zone.
Oh great. So you basically use as much as possible
- the AWS region that powers you. - Exactly.
- Great, perfect. - So you were saying that in the ECS clusters
you have also implemented other features
other than API.
Correct. We have some workers on the ECS cluster,
so it's a second level of micro-services
which communicates with the first level that exposes API
through the SQS queues.
These workers manage the events that are generated on the platform.
The events can be also managed in real time
or scheduled.
For the scheduled events we have in particular, three micro-services
that allow our users to create, schedule and defer
some campaigns towards the messaging applications.
Great, excellent. A very interesting case.
How would this application evolve?
How are you planning to develop it further in the future?
The application has been launched just a few months ago.
We are thinking of implementing the support
for other applications for instant messaging,
other than the ones that are already available.
- That is great. Thanks Paolo. - Thank you.
And thank you all for watching This Is My Architecture.