0

I'm trying to realize a service that executes operations at a certain time, those operations are specified by another service by messaging, here's the scenario:

  • The service A receives a request to create an object, the service stores the object in its own database
  • For every object, an operation must be executed at a given time specified in the object
  • Trying to estabilish some business boundaries, the service B will be responsible for the execution of the above mentioned operations; this is because the role of the operation is to create a session accessible to clients (think it like a chat room that starts at X time and ends at Y time)
  • I'm attempting to follow a coreographic architecture, so I would like for the service B to know what operations to execute and when to execute them
  • According to this, service A will just send messages to the service B about what operations to execute and when they need to be executed

The problem is what is the best strategy for service B to achieve this once it receives messages; I thought of 2 solutions:

  1. Once the service B receives a message, it stores the informations on a dedicated database; the service can then check every X time the operations to be executed on the DB, but this can affect performance, since it requires continuous access and query to the database
  2. Once the service B receives a message, it starts a timer that will execute the operations at the given time; this will reduce operations to the minimum required, but if the service falls for any reason, all timers would be gone. This would imply writing logic to restore timers gone and already started ones.

I don't know if these are the best solutions; is there another strategy that I can use? Thanks

Improve this question

1 Answer 1

Reset to default
2

Depends a bit on how frequent these events are. Here, “frequent” would mean that if you use a polling solution that queries the database for events that have to be executed, you'd get an average of at least one event per query.

For such frequent events, polling is perfectly fine. You will have to hit the database anyway to retrieve details about the event. Furthermore, if your polling frequency is fairly low then these queries do not add noticeable load to your database. Queries on well-designed databases complete in milliseconds. So event a polling frequency of a few times per second would be fine.

If the events are very rare and queries are very expensive, then using timers is useful as an optimization. These timers are not a source of truth, these timers just let you skip queries that you know won't produce new results. If the service has to restart you do a query for the next upcoming event, set a timer, and go to sleep until then. When the set of events is changed, the timer may have to be recalculated. You only need a single timer until the next query, not individual timers for each event.

This approach is e.g. used on mobile devices where processes should wake up the device as rarely as possible for energy conservation reasons (events are rare and queries expensive). In contrast, you likely do not have comparable restrictions in an enterprise microservice setting. There, juggling timers is possibly that kind of feature where developing it costs more than it would save (until you hit massive scale). If minimizing infrastructure costs was the main motivation, microservices might not be an appropriate choice anyway.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.