How to model time in CQRS/ES system

[Denis Mikhaylov]

Hi! I wonder how to model time in CQRS/ES systems.

e.g. in a billing system how do I create a Schedule for recurrent monthly payment?

Should I delegate it to Chronos or other schedule middleware? 

Or should I create distributed (sharded by period) scheduling process which then will get fed with periodic ClockTicked events and issue registered commands?

[Greg Young]

Sending your future self messages is very useful for scheduling. See
my talk from dddx about the subject
https://skillsmatter.com/skillscasts/5437-answering-a-question#video

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Denis Mikhaylov]

Thanks, Greg. Will take a look.

> You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/8wIQ9mdQPKI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Denis Mikhaylov]

I watched your video. 

The question I was asking is how exactly do I send message to future self? 

Is it infrastructure concerns or billing schedule is a part of a domain and should be implemented by means of ARs and process managers?

четверг, 16 июня 2016 г., 13:21:31 UTC+3 пользователь Greg Young написал:

[Greg Young]

What you are looking for is the concept of a delayed publish. Many
messaging middlewares support this concept. If you want to avoid
middleware implementing a simple one on your own is not a difficult
exercise. The real questions are more things like "does it need to be
durable or is in memory good enough?" "What level of granularity is
needed" for high granularity (minutes) cron can do this pretty well :)

[Denis Mikhaylov]

I use Kafka as message bus, so no go. 

Granularity is about 1 hour, however cron and distributed systems don't go well :)

четверг, 16 июня 2016 г., 16:57:47 UTC+3 пользователь Greg Young написал:

[Greg Young]

"Granularity is about 1 hour, however cron and distributed systems
don't go well :)"

At a granularity of one hour it would most likely be fine unless you
are very high message volumes.

What is your message throughput?

[Denis Mikhaylov]

Not much I expect around 1 scheduled command per second. 

By distributed I mean 3 node cluster.

четверг, 16 июня 2016 г., 17:28:32 UTC+3 пользователь Greg Young написал:

[Greg Young]

See chronos http://nerds.airbnb.com/introducing-chronos/

but even running a single node with cron in your case would likely be
acceptable.

[Denis Mikhaylov]

Losing this node would break everything then.

> You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/8wIQ9mdQPKI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

At a granularity of hours this likely wouldn't matter. To be fair even
if you "lost" this node you could realize this with a trivial level of
monitoring and have it back in minutes at most.