We at MiQ bid for billions of impressions every day. This comes at a cost and many technical challenges. After the ad is served we need a mechanism to share insights with clients. We need an application to gather these insights on a periodic basis.
Building microservices is comparatively easy but the more difficult part is everything that happens between the services in distributed systems. That’s where orchestration frameworks like Kubernetes come to rescue. At the same time, microservices need t to minimize synchronous invocations for intra-microservices communications to ensure the best possible isolation. Instead, architects should consider using asynchronous communication between the services. This is why reactive libraries like the ones from the ReactiveX programming, the family has become so popular.
A well-written microservice is generally going to apply the principles of the reactive manifesto. One could assert that a microservices architecture is just an extension of the reactive manifesto that is geared towards web services. But there are related subjects of reactive programming and functional reactive programming which are related to the reactive manifesto. A system can be a reactive system and not use a reactive programming model. Reactive programming is often used to coordinate asynchronous calls to multiple services along with events and streams from clients.
Reactive microservices enabled us to keep the resource costs minimum with a highly scalable, efficient ecosystem. In this session, we dig deeper into the multiple aspects of the challenges, sneak peek with the architecture of the system that keeps delivering for our clients.
6. 6
Daily Scale at MiQ
10+ TB
Data
Avg
response
time per
request
< 7ms
Real time
data
processing
< 1sec
60+ Data
sources
integrations
900,000
CPU
minutes
everyda
y
80
Billion
Ad
Impressi
ons
750
million
users
600+
advertiser
s
2500+
campai
gns
Tech Stats
Volume
Scale
Variety Velocity
7. 7
So we wanted
to slice the
Almighty
monolith and
move towards
microservices
11. 11
Reactive Microservices
Isolate All The things Act Autonomously Do One Thing, Do It Well
Own Your state,
Exclusively
Embrace Asynchronous
Message-Passing
Stay Mobile, but
Addressable
12. 12
Microservices come in systems
One microservice is no microservice
Discovery Coordination Security Replication Consistency Failover Deployment Integration
13. 13
Event driven architecture is a design
paradigm in which a software component
executes in response to receiving one or
more notifications.
- GARTNER
Event Driven
Architecture To
Rescue
14. 14
Event Driven Services
Receive and
react(or not) to
the facts
coming its way
Publish new facts (as
events) to the rest of
the world
Invert the control
flow to minimize
the coupling and
increase
autonomy
Go Async, never block
Always apply
backpressure
Fast system should never
overload slow system
16. 16
A CURE FOR CARDINAL SIN
Discussing the flow of events in your
organization and modelling that flow
in an easy to understand way.
Event Command
Aggregate Input
Policy
External
System
Event Storming
18. 18
Domain Driven Design
Aggregate Bounded Context
An Account
aggregate that
logically groups
account-related
commands and
events.
bounded contexts group
related language,
meaning, and culture
[bulkheads]
19. 19
Event Sourcing
Advantages
2019
Disadvantages
➢ One single source of truth with
all history
➢ Allows the memory image -
durable in-memory state
➢ Avoids the object relational
impedance mismatch
➢ Allows others to subscribe to
state change
➢ Unfamiliar model
➢ Versioning of events
➢ Deletion of events (moral or
legal reasons)