Concept of services, tags, and arguments I defined a service using the following code.

services:
  redirect.repository:
    class: Drupal\redirect\RedirectRepository
    arguments: ['@entity.manager', '@database', '@config.factory']
    tags:
      - { name: backend_overridable }


According to my understanding, '@entity.manager' , '@database', and '@config.factory' are classes on which the service is dependent.

Now, the entity.manager service definition is the following.

class: Drupal\Core\Entity\EntityManager
parent: container.trait
tags:
  - { name: plugin_manager_cache_clear }


It has a tag associated with it. Maybe this tag manages all entity specific cache.

What is the responsibility of the redirect.repository services?
Does this service help communicating with the database directly?
What if I don't have any entity and I implemented hook_schema()? Can I mention my custom database table name instead of @entity.manager?
Where do these tags actually get registered?
1. Database

redirect.repository communicates with the database through its usage of the class represented by the database service injected into its initialize method (__construct). However the RedirectRepository class does not itself use PDO to connect to the database.

The redirect module has chosen not to implement an entity to store its data, and is an example of using Drupal's database abstraction layer (DBAL) from the database service.

// Load redirects by hash. A direct query is used to improve performance.
$rid = $this-&gt;connection
  -&gt;query('SELECT rid FROM {redirect} WHERE hash IN (:hashes[]) ORDER BY LENGTH(redirect_source__query) DESC', [':hashes[]' =&gt; $hashes])
  -&gt;fetchField();


2. Entity Manager

The entity.manager service provides a deprecated helper class to make it easier to get information about entities only. If you do not implement an entity, then you cannot use any of the entity-related services such as entity.manager or entity_type.manager.

3. Dependency Injection Tags


  Dependency Injection Tags are little strings that can be applied to a
  service to "flag" it to be used in some special way. For example, if
  you have a service that you would like to register as a listener to
  one of Symfony's core events, you can flag it with the
  kernel.event_listener tag.


Tags are treated specially so that when the service container is "compiled" certain classes may be able to make a second "compiler pass" and act on services that are tagged.

See the Symfony2 documentation for more details about compiler passes: http://symfony.com/doc/current/components/dependency_injection/compilation.html#components-di-separate-compiler-passes