0

I'm about to start a small personal project that would expose an API about my stock portfolio. To achieve that I would have to fetch data from 3 APIs(My stock broker, one stats API and one to get extended hour prices of stocks) on a schedule, then calculate certain stats and expose them with via REST service, which would be the final goal. I'm planning to separate the app into two services. The first one would communicate with the external APIs and store their information into a DB and the other would calculate the stats I need and expose the REST service.

I imagine it would look something like this: enter image description here

The blue part would be my two microservices.

I initially thought that this looks like a good design. The two services have two separate concerns and if each of them fails, the other would be completely usable. However, since they both would work with the same DB tables that would mean that I will have the same domain classes in both of my services. I don't like that repetition of code and then I thought that whatever kind of data that I would like to share between those two services should be replicated in both of them.

I have no experience in such architectures and I'm really curious how you've solved similar problems before.

Dimo Georgiev
  • 55
  • 1
  • 9

2 Answers2

2

I would have three modules:

  • Core: This module would be responsible for actually storing and retrieving the stocks from the database.
  • Extractor/Scheduling: This module would be responsible for extracting information from external sources and submitting them to the Core module.
  • API/APIGateway: This module would be responsible for receiving incoming traffic. It could be merged with the Core module depending on the requirements.
lkatiforis
  • 5,703
  • 2
  • 16
  • 35
  • I really like the idea! However, the classes for the objects that are stored in the DB would have to be present in all 3 of those services, or am I getting this wrong? – Dimo Georgiev Sep 12 '21 at 14:02
  • 1
    Entity classes would have to be present only in the Core module. The API and Scheduling modules would have DTOs (data transfer objects) classes. You may want to package all of your DTOs to a common library and use it as a dependency. Check the difference between Entities and DTOs here: https://stackoverflow.com/questions/39397147/difference-between-entity-and-dto – lkatiforis Sep 12 '21 at 14:20
1

Ideally, in a true microservice architecture, you should not share Databases. Why? By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements.

Having said that you should really consider moving to two separate databases or merging the services into one.

If you really want to go forward with two services and a single database (which I don't really recommend) you could then build a lib containing the database entities and maybe even the DAOs/Repositories. You would then make this lib a dependency of your two services.

João Dias
  • 16,277
  • 6
  • 33
  • 45
  • Thanks for the suggestion Joao! And in case I want to share data between those two microservices via REST calls (instead of shared DB), wouldn't I also need to have the class that is used to send JSON in both services? – Dimo Georgiev Sep 12 '21 at 14:00
  • 1
    Yes, that is in fact true. Then again, following the microservices architecture, you should have the class separated in both services because there should be no dependency between the two microservices. However, if you don't really like this, you can create the lib with the shared model and make it a dependency on both services. But keep in mind this is against microservices standards. – João Dias Sep 12 '21 at 14:04